argc - cant access memory

argc - cant access memory

[Hadron]

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?

Re: argc - cant access memory

[Jim Blandy]

Hadron <hadronquark@googlemail.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?

Re: argc - cant access memory

[Nick Roberts]

 > > 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.nz/~nickrob

Re: argc - cant access memory

[Hadron]

Nick Roberts <nickrob@snap.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.


 

RE: argc - cant access memory

[Dave Korn]

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....

Re: argc - cant access memory

[Daniel Jacobowitz]

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

RE: argc - cant access memory

[Dave Korn]

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....

Re: argc - cant access memory

[Jim Blandy]

"Dave Korn" <dave.korn@artimi.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 <sleep@plt>
    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.

Re: argc - cant access memory

[Jim Blandy]

Hadron <rileyrg@googlemail.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.