argc - cant access memory

I recently compiled and executed an opengl programming guide
(redbook)
example, hello.c, successfully. However, when I try to debug
it under
GUD I get

,----
| #0  main (argc=Cannot access memory at address 0x2d
| ) at hello.c:93
`----

The code can be found here:

http://opengl-redbook
.com/code/

but is pasted below for convenience.

It is compiled using the following Linux based makefile:

,----
| CC=gcc
| COMPILE.c=$(CC) $(CFLAGS) -c
| LINK.c=$(CC) $(CFLAGS) $(LDFLAGS)
| LDLIBS=$(EXTRALIBS)
| CFLAGS= -std=c99 -pedantic -Wall -D_GNU_SOURCE -g
| 
| GLUT = -lglut
| EXTRALIBS = $(GLUT) -lGLU -lGL -lXmu -lXext -lX11 -lm
| 
| PROGS =  
| 		  aaindex aargb accanti accpersp alpha3D 
| 		  alpha bezcurve bezmesh bezsurf blendeqn 
| 		  checker clip colormat combiner cubemap 
| 		  cube dof double drawf feedback 
| 		  fogcoord fogindex fog font hello 
| 		  image light lines list material 
| 		  mipmap model movelight multisamp multitex 
| 		  mvarray pickdepth picksquare planet pointp 
| 		  polyoff polys quadric robot scene 
| 		  select shadowmap smooth stencil stroke 
| 		  surface surfpoints teapots tesswind tess 
| 		  texbind texgen texprox texsub texture3d 
| 		  texturesurf torus trim unproject varray 
| 		  wrap
| 
| IMAGING_SUBSET = colormatrix colortable convolution
histogram minmax blendeqn
| 
| all:	$(PROGS)
| 
| clean:
| 	rm -f $(PROGS)
`----

The code is:

,----
| /*
|  * hello.c
|  * This is a simple, introductory OpenGL program.
|  */
| #include <GL/glut.h>
| #include <stdlib.h>
| 
| void display(void)
| {
| /* clear all pixels  */
|    glClear (GL_COLOR_BUFFER_BIT);
| 
| /* draw white polygon (rectangle) with corners at
|  * (0.25, 0.25, 0.0) and (0.75, 0.75, 0.0)  
|  */
|    glColor3f (1.0, 1.0, 1.0);
|    glBegin(GL_POLYGON);
|       glVertex3f (0.25, 0.25, 0.0);
|       glVertex3f (0.75, 0.25, 0.0);
|       glVertex3f (0.75, 0.75, 0.0);
|       glVertex3f (0.25, 0.75, 0.0);
|    glEnd();
| 
| /* don't wait!  
|  * start processing buffered OpenGL routines 
|  */
|    glFlush ();
| }
| 
| void init (void) 
| {
| /* select clearing color 	*/
|    glClearColor (0.0, 0.0, 0.0, 0.0);
| 
| /* initialize viewing values  */
|    glMatrixMode(GL_PROJECTION);
|    glLoadIdentity();
|    glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);
| }
| 
| /* 
|  * Declare initial window size, position, and display
mode
|  * (single buffer and RGBA).  Open window with
"hello"
|  * in its title bar.  Call initialization routines.
|  * Register callback function to display graphics.
|  * Enter main loop and process events.
|  */
| int main(int argc, char** argv)
| {
|    glutInit(&argc, argv);
|    glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB);
|    glutInitWindowSize (250, 250); 
|    glutInitWindowPosition (100, 100);
|    glutCreateWindow ("hello");
|    init ();
|    glutDisplayFunc(display); 
|    glutMainLoop();
|    return 0;   /* ANSI C requires main to return int. */
| }
`----

It is not on all lines in main that I get this error.

Ideas?

Hadron <hadronquarkgooglemail.com> writes:
> I recently compiled and executed an opengl programming
guide (redbook)
> example, hello.c, successfully. However, when I try to
debug it under
> GUD I get
>
> ,----
> | #0  main (argc=Cannot access memory at address 0x2d
> | ) at hello.c:93
> `----

The code you labeled "hello.c" has no line 93. 
Are you sure you're
debugging the program you intended to?

 > > I recently compiled and executed an opengl
programming guide (redbook)
 > > example, hello.c, successfully. However, when I
try to debug it under
 > > GUD I get
 > >
 > > ,----
 > > | #0  main (argc=Cannot access memory at address
0x2d
 > > | ) at hello.c:93
 > > `----
 > 
 > The code you labeled "hello.c" has no line
93.  Are you sure you're
 > debugging the program you intended to?

Aside from that, I think it just means that the arguments
have been optimised
away.  I think current GCC does this now even if the user
doesn't specify
optimisation.  It doesn't stop you from debugging does it?

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

Nick Roberts <nickrobsnap.net.nz> writes:

>  > > I recently compiled and executed an opengl
programming guide (redbook)
>  > > example, hello.c, successfully. However,
when I try to debug it under
>  > > GUD I get
>  > >
>  > > ,----
>  > > | #0  main (argc=Cannot access memory at
address 0x2d
>  > > | ) at hello.c:93
>  > > `----
>  > 
>  > The code you labeled "hello.c" has no
line 93.  Are you sure you're
>  > debugging the program you intended to?
>
> Aside from that, I think it just means that the
arguments have been optimised
> away.  I think current GCC does this now even if the
user doesn't specify
> optimisation.  It doesn't stop you from debugging does
it?

There is no 93 you are right as I
clipped the header. Mea culpa.

As for optimizing the arguments away, wouldn't this be the
case for all
the lines referencing argc in the main()? But is this the
typical
"error" for such a case?

I get the message after stepping over the first line in main
and then
when I get to line 3 (in main) then I get

#0  main (argc=191860, argv=0xb7f49850) at hello.c:94

(94 is the line "glutInitWindowSize (250, 250);"
in main)

If you say this is normal behaviour then fine, but I haven't
experienced
it before. I would be interested to hear if you get the
same.


 

On 10 July 2007 13:13, Hadron wrote:


> As for optimizing the arguments away, wouldn't this be
the case for all
> the lines referencing argc in the main()? But is this
the typical
> "error" for such a case?

  Ah, I've just recognised what's going on here, this is not
optimisation,
that's a red herring.
 
> I get the message after stepping over the first line in
main and then
> when I get to line 3 (in main) then I get
> 
> #0  main (argc=191860, argv=0xb7f49850) at hello.c:94
> 
> (94 is the line "glutInitWindowSize (250,
250);" in main)
> 
> If you say this is normal behaviour then fine, but I
haven't experienced
> it before. I would be interested to hear if you get the
same.

  This is normal behaviour.  It's nothing to do with
optimisation: it's just
that gdb breakpoints at the very start of the function
epilogue, but none of
the arguments parameters are accessible in the expected
places indicated by
the debug info until after the epilogue has created the
stack frame, etc.

  Try this with any function you like: set a breakpoint on
the very first line
- the one with the opening '{' of the function, run until
you hit the
breakpoint.  You'll see nonsense in the locals and
arguments.  Now use the
'next' function to step over the opening brace - which
amounts to stepping
over the function epilogue - and suddenly all those
variables will spring into
being with their correct values.

  It's a cosmetic glitch that gdb fails to say something
like "not in scope"
before the prologue has completed.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

On Tue, Jul 10, 2007 at 08:41:40PM +0100, Dave Korn wrote:
>   This is normal behaviour.  It's nothing to do with
optimisation:

Actually, I expect this is the problem specific to
"main" that we've
seen before; it is caused by stack alignment code that
recent GCCs
emit on x86, to accomodate SSE.

-- 
Daniel Jacobowitz
CodeSourcery

On 10 July 2007 20:47, Daniel Jacobowitz wrote:

> On Tue, Jul 10, 2007 at 08:41:40PM +0100, Dave Korn
wrote:
>>   This is normal behaviour.  It's nothing to do
with optimisation:
> 
> Actually, I expect this is the problem specific to
"main" that we've
> seen before; it is caused by stack alignment code that
recent GCCs
> emit on x86, to accomodate SSE.

  Ah, is the stack adjustment code not marked as
frame-related?  I guess that
would do it ...

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Hadron <rileyrggooglemail.com> writes:
> I get the message after stepping over the first line in
main and then
> when I get to line 3 (in main) then I get
>
> #0  main (argc=191860, argv=0xb7f49850) at hello.c:94
>
> (94 is the line "glutInitWindowSize (250,
250);" in main)
>
> If you say this is normal behaviour then fine, but I
haven't experienced
> it before. I would be interested to hear if you get the
same.

This really looks like what happens when you debug optimized
code.
The compiler emits debugging information that doesn't
accurately
relate the machine code it generated to the original source.
 If this
is the case, there isn't much a debugger can do about it. 
You might
try re-compiling without optimization.

But the make fragment you posted didn't look like it was
compiled with
optimization.  Without optimization, the compiler is
supposed to
generate code which behaves as expected under the debugger;
from the
GCC manual:

     Without any optimization option, the compiler's goal is
to reduce
    the cost of compilation and to make debugging produce
the expected
    results.  Statements are independent: if you stop the
program with
    a breakpoint between statements, you can then assign a
new value
    to any variable or change the program counter to any
other
    statement in the function and get exactly the results
you would
    expect from the source code.

"Dave Korn" <dave.kornartimi.com> writes:
>   This is normal behaviour.  It's nothing to do with
optimisation: it's just
> that gdb breakpoints at the very start of the function
epilogue, but none of
> the arguments parameters are accessible in the expected
places indicated by
> the debug info until after the epilogue has created the
stack frame, etc.
>
>   Try this with any function you like: set a breakpoint
on the very first line
> - the one with the opening '{' of the function, run
until you hit the
> breakpoint.  You'll see nonsense in the locals and
arguments.  Now use the
> 'next' function to step over the opening brace - which
amounts to stepping
> over the function epilogue - and suddenly all those
variables will spring into
> being with their correct values.
>
>   It's a cosmetic glitch that gdb fails to say
something like "not in scope"
> before the prologue has completed.

Daniel's explanation is right, but I wanted to clarify
something here:

As long as GDB is properly interpreting the debugging info
it has
(which in this case it is), then this isn't GDB's problem to
solve;
it's GCC's.  GDB can only debug the program as described by
the
debugging information.  The fault here is in GCC for not
properly
describing the code it produced.

Especially nowadays, there is no clear boundary between the
prologue
and the body code; body instructions may be mixed in with
prologue
instructions.  This means that it's not possible for GDB to
accurately
declare variables "not in scope" until the end of
the prologue.

DWARF does have the features required for the compiler to
accurately
describe every variable's location at every point in the
code, even in
the prologue, or at the function's entry point.  And GDB
understands
that info (although it can't assign to variables in some
cases).

The code I see is:

    (gdb) disass main
    Dump of assembler code for function main:
    0x08048354 <main+0>:	lea    0x4(%esp),%ecx
    0x08048358 <main+4>:	and    $0xfffffff0,%esp
    0x0804835b <main+7>:	pushl  0xfffffffc(%ecx)
    0x0804835e <main+10>:	push   %ebp
    0x0804835f <main+11>:	mov    %esp,%ebp
    0x08048361 <main+13>:	push   %ebx
    0x08048362 <main+14>:	push   %ecx
    0x08048363 <main+15>:	sub    $0x10,%esp
    0x08048366 <main+18>:	mov    %ecx,%ebx
    0x08048368 <main+20>:	movl   $0x1,(%esp)
    0x0804836f <main+27>:	call   0x8048298
<sleepplt>
    0x08048374 <main+32>:	mov    (%ebx),%eax
    0x08048376 <main+34>:	add    $0x10,%esp
    0x08048379 <main+37>:	pop    %ecx
    0x0804837a <main+38>:	pop    %ebx
    0x0804837b <main+39>:	pop    %ebp
    0x0804837c <main+40>:	lea   
0xfffffffc(%ecx),%esp
    0x0804837f <main+43>:	ret    
    End of assembler dump.

The 'lea' saves the frame's base address in %ecx; the 'and'
aligns the
stack pointer.  At that point, there's no fixed relationship
between
the stack pointer and the base of the frame; it depends on
how
misaligned the sp was originally.  We save %ebp and set it
from the
aligned stack pointer.

Here's the output from readelf -wfF, referring to %esp as
'r4',
%ecx as 'r1', and %ebp as 'r5':

    The section .eh_frame contains:

    00000000 ZERO terminator


    The section .debug_frame contains:

    00000000 00000010 ffffffff CIE "" cf=1 df=-4
ra=8
       LOC   CFA      ra   
    00000000 r4+4     c-4  

    00000014 00000024 00000000 FDE cie=00000000
pc=08048354..08048380
       LOC   CFA      r3   r4   r5   ra   
    08048354 r4+4     u    u    u    c-4  
    08048358 r1+0     u    r1   u    c-4  
    0804835e r4+4     u    r1   u    c-4  
    0804835f r4+8     u    r1   c-8  c-4  
    08048361 r5+8     u    r1   c-8  c-4  
    08048363 r5+8     c-12 c-16 c-8  c-4  

After the 'and' at 0x08048358, the CFA should always be
%ecx+0, but as
you can see, the CFI emitted by GCC incorrectly reverts to
offsets
from %esp and %ebp.