gdb problems with -O1 on x86_64 architecture.

gdb problems with -O1 on x86_64 architecture.

[Tigran Aivazian]

Hello,

I enclosed a small program which shows a bug in gdb --- it coredumps if 
you try to look at the backtrace. Here is how to reproduce it:

1. Compile with -O1 optimization option:

$ gcc -g -Wall -O1 uvar.c -o uvar-O1

2. Run gdb from Friday's CVS (or any other) on it:

# /usr/local/src/6.3/gdb-cvs/src-bin-orig/gdb/gdb uvar-O1
GNU gdb 6.3.50.20050506-cvs
[skip copyright msg]
(gdb) set radix 16
Input and output radices now set to decimal 16, hex 10, octal 20.
(gdb) b kt_func3
Breakpoint 1 at 0x4004d8: file uvar.c, line 10.
(gdb) r
Starting program: /root/mod/uvar-O1

Breakpoint 1, kt_func3 (x1=0x11111133, x2=0x22222244, x3=0x33333355, 
x4=0x44444466, x5=0x55555577,
Segmentation fault

Now, look at the core dump:

(gdb) bt
#0  dwarf_expr_frame_base (baton=0x7fbfffe940, start=0x7fbfffe8d8, 
length=0x7fbfffe8e0) at dwarf2loc.c:174
#1  0x000000000055f1d3 in execute_stack_op (ctx=0x8c57b0, op_ptr=0x8ae177 
"\016x9", op_end=0x8ae177 "\016x9")
     at dwarf2expr.c:465
#2  0x0000000000512e57 in dwarf2_evaluate_loc_desc (var=0x8bebf0, 
frame=0x825ad0,
     data=0x8ae175 "\221\020\016x9", size=2, objfile=<value optimized out>) 
at dwarf2loc.c:301
#3  0x000000000049f86b in read_var_value (var=0x8bebf0, frame=0x825ad0) at 
findvar.c:569
#4  0x00000000004d3750 in print_frame_args (func=<value optimized out>, 
fi=0x825ad0, num=-1, stream=0x844b20)
     at stack.c:351
#5  0x00000000004d3f79 in print_args_stub (args=<value optimized out>) at 
stack.c:404
#6  0x00000000004d7464 in catch_errors (func=0x4d3f50 <print_args_stub>, 
func_args=0x7fbfffeb10,
     errstring=0x5ea36f "", mask=<value optimized out>) at exceptions.c:518
#7  0x00000000004d5281 in print_frame_info (fi=0x825ad0, print_level=0, 
print_what=SRC_AND_LOC, print_args=1)
     at stack.c:667
#8  0x00000000004d581d in print_stack_frame_stub (args=0x7fbfffecd0) at 
stack.c:138


Now looking in gdb/dwarf2loc.c:dwarf_expr_frame_base() function we see the 
offending C code at line 174:

*length = symbaton->size;

Anyone working on this bug? I opened an incident in gdb bug database, 
reference "symtab/1939: gdb coredumps on -O1 compiled binary on x86_64".

Also, with application compiled with -O0 everything works perfectly. But 
with -O2 I get most of the function arguments marked as "optimized away". 
Well, surely they are NOT optimized away, but the debug info is stored in 
such a way (presumably difficult to decode according to DWARF2 rules) that 
makes gdb's life very hard to decode them, right? Is there any way to get 
gdb to see function arguments for the case of -O2 optimization?

Kind regards
Tigran


#include <stdio.h>

struct kt_struct {
 	int kt_field1;
 	int kt_field2;
 	char kt_name[16];
} kt_var;

int kt_func3(int x1, int x2, int x3, int x4, int x5, int x6, int x7, int x8, int x9)
{
 	return (x1 + x2 + x3/2 + x4/4 + x5/5 + x6/6 + x7/7 + x8/8 + x9/9); 
}

int kt_func2(int x1, int x2, int x3, int x4, int x5, int x6, int x7, int x8, int x9)
{
 	return kt_func3(x1 + 0x11, x2 + 0x11, x3 + 0x11, x4 + 0x11, x5 + 0x11, x6 + 0x11,
 			x7 + 0x11, x8 + 0x11, x9 + 0x11);
}

int kt_func1(int x1, int x2, int x3, int x4, int x5, int x6, int x7, int x8, int x9)
{
 	return kt_func2(x1 + 0x11, x2 + 0x11, x3 + 0x11, x4 + 0x11, x5 + 0x11, x6 + 0x11,
 			x7 + 0x11, x8 + 0x11, x9 + 0x11);
}

int main(int argc, char *argv[])
{
 	int x;
 	kt_var.kt_field1 = 0xAA;
 	x = kt_func1(0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x55555555, 0x66666666,
 		     0x77777777, 0x88888888, 0x99999999);
 	printf("kt_exit() x=%x\n", x);
 	kt_var.kt_field1 = 0xBB;
 	return 0;
}

Re: gdb problems with -O1 on x86_64 architecture.

[Daniel Jacobowitz]

On Mon, May 09, 2005 at 05:11:27PM +0100, Tigran Aivazian wrote:
> Hello,
> 
> I enclosed a small program which shows a bug in gdb --- it coredumps if 
> you try to look at the backtrace. Here is how to reproduce it:
> 
> 1. Compile with -O1 optimization option:
> 
> $ gcc -g -Wall -O1 uvar.c -o uvar-O1

It is unlikely that anyone else can reproduce this, because it depends
on what your compiler is generating.  What version is it?  What patches
are applied?

You may have better luck if you attach a built binary.

> Also, with application compiled with -O0 everything works perfectly. But 
> with -O2 I get most of the function arguments marked as "optimized away". 
> Well, surely they are NOT optimized away, but the debug info is stored in 
> such a way (presumably difficult to decode according to DWARF2 rules) that 
> makes gdb's life very hard to decode them, right? Is there any way to get 
> gdb to see function arguments for the case of -O2 optimization?

No, more likely they are optimized away - not saved because they are no
longer available.  There's no way to be sure without a binary.  In your
test case, they probably _are_ gone.  They are never referenced after
the function calls, so there's no benefit in saving them to the stack
and restoring them later.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb problems with -O1 on x86_64 architecture.

[Tigran Aivazian]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 726 bytes --]

Hi Daniel,

Thank you for the quick response.

On Mon, 9 May 2005, Daniel Jacobowitz wrote:
> It is unlikely that anyone else can reproduce this, because it depends
> on what your compiler is generating.  What version is it?  What patches
> are applied?

It is SLES9, here is gcc --version output:

# gcc --version
gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

>
> You may have better luck if you attach a built binary.

Ok, attached. I don't know if the list manager passes it through, but at 
least you should get it.

Kind regards
Tigran

[-- Attachment #2: uvar-O1 --]
[-- Type: APPLICATION/octet-stream, Size: 15866 bytes --]

Re: gdb problems with -O1 on x86_64 architecture.

[Tigran Aivazian]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1688 bytes --]

Hi,

I thought it is worth showing how it behaves on -O2 compiled binary as 
well:

# gcc -g -Wall -O2 -fno-optimize-sibling-calls uvar.c -o uvar-O2

(gdb) b kt_func3
Breakpoint 1 at 0x4004e0: file uvar.c, line 11.
(gdb) r
Starting program: /root/mod/uvar-O2

Breakpoint 1, kt_func3 (x1=0x11111133, x2=0x22222244, x3=0x33333355, 
x4=0x44444466, x5=0x55555577, x6=0x66666688,
     x7=0x77777799, x8=0x888888aa, x9=0x9566b560) at uvar.c:11
11              return (x1 + x2 + x3/2 + x4/4 + x5/5 + x6/6 + x7/7 + x8/8 
+ x9/9);
(gdb) bt
#0  kt_func3 (x1=0x11111133, x2=0x22222244, x3=0x33333355, x4=0x44444466, 
x5=0x55555577, x6=0x66666688, x7=0x77777799,
     x8=0x888888aa, x9=0x9566b560) at uvar.c:11
#1  0x00000000004005d3 in kt_func2 (x1=<value optimized out>, x2=<value 
optimized out>, x3=<value optimized out>,
     x4=<value optimized out>, x5=<value optimized out>, x6=<value 
optimized out>, x7=0x77777788, x8=0x88888899,
     x9=0x999999aa) at uvar.c:16
#2  0x0000000000400623 in kt_func1 (x1=<value optimized out>, x2=<value 
optimized out>, x3=<value optimized out>,
     x4=<value optimized out>, x5=<value optimized out>, x6=<value 
optimized out>, x7=0x77777777, x8=0x88888888,
     x9=0x99999999) at uvar.c:22
#3  0x000000000040067a in main (argc=<value optimized out>, argv=<value 
optimized out>) at uvar.c:30

As you see, it claims that x1,x2,x3,x4,x5,x6 are optimized out and 
x7,x8,x9 are available and shows the correct values. This is for kt_func2 
and kt_func1 functions, but for kt_func3 it shows all values correctly 
except the last one --- x9 is garbage. But with -O0 it shows everything 
correctly.

I attached the -O2 compiled uvar as well.

Kind regards
Tigran

[-- Attachment #2: uvar-O2 --]
[-- Type: APPLICATION/octet-stream, Size: 15978 bytes --]

Re: gdb problems with -O1 on x86_64 architecture.

[Daniel Jacobowitz]

On Tue, May 10, 2005 at 03:33:31PM +0100, Tigran Aivazian wrote:
> Hi,
> 
> I thought it is worth showing how it behaves on -O2 compiled binary as 
> well:
> 
> # gcc -g -Wall -O2 -fno-optimize-sibling-calls uvar.c -o uvar-O2
> 
> (gdb) b kt_func3
> Breakpoint 1 at 0x4004e0: file uvar.c, line 11.
> (gdb) r
> Starting program: /root/mod/uvar-O2
> 
> Breakpoint 1, kt_func3 (x1=0x11111133, x2=0x22222244, x3=0x33333355, 
> x4=0x44444466, x5=0x55555577, x6=0x66666688,
>     x7=0x77777799, x8=0x888888aa, x9=0x9566b560) at uvar.c:11
> 11              return (x1 + x2 + x3/2 + x4/4 + x5/5 + x6/6 + x7/7 + x8/8 
> + x9/9);
> (gdb) bt
> #0  kt_func3 (x1=0x11111133, x2=0x22222244, x3=0x33333355, x4=0x44444466, 
> x5=0x55555577, x6=0x66666688, x7=0x77777799,
>     x8=0x888888aa, x9=0x9566b560) at uvar.c:11
> #1  0x00000000004005d3 in kt_func2 (x1=<value optimized out>, x2=<value 
> optimized out>, x3=<value optimized out>,
>     x4=<value optimized out>, x5=<value optimized out>, x6=<value 
> optimized out>, x7=0x77777788, x8=0x88888899,
>     x9=0x999999aa) at uvar.c:16
> #2  0x0000000000400623 in kt_func1 (x1=<value optimized out>, x2=<value 
> optimized out>, x3=<value optimized out>,
>     x4=<value optimized out>, x5=<value optimized out>, x6=<value 
> optimized out>, x7=0x77777777, x8=0x88888888,
>     x9=0x99999999) at uvar.c:22
> #3  0x000000000040067a in main (argc=<value optimized out>, argv=<value 
> optimized out>) at uvar.c:30
> 
> As you see, it claims that x1,x2,x3,x4,x5,x6 are optimized out and 
> x7,x8,x9 are available and shows the correct values. This is for kt_func2 
> and kt_func1 functions, but for kt_func3 it shows all values correctly 
> except the last one --- x9 is garbage. But with -O0 it shows everything 
> correctly.

GDB's doing the best it can.  Let me give you a case-by-case.  First
the top frame.  We're at 0x4004e0; presumably because this function
does not appear to have a prologue.  Debuginfo says:
   x1 in reg5, but only for the first two instructions, then dead
   x2 in reg4
   x3 in reg1 until +0x14
   x4 in reg2
   ...
   x9 in reg3

Well, reg3 is %rbx and that's just not true.

  4004e4:       53                      push   %rbx
  4004f7:       8b 5c 24 20             mov    0x20(%rsp),%ebx

_NOW_ it's in rbx.  The compiler didn't tell us that the variable came
in on the stack and then moved to %rbx, it said it was in %rbx the
whole time.  This is a (very common) compiler bug; it's rare that a
compiler tracks incoming argument locations properly.  I hope GCC does
someday.

How about for the next frame?  Let's look at 0x00000000004005d3 in
kt_func2.  Please take a look at the code for a moment.

  400590:       48 83 ec 18             sub    $0x18,%rsp
  400594:       41 83 c1 11             add    $0x11,%r9d
  400598:       41 83 c0 11             add    $0x11,%r8d
  40059c:       8b 44 24 30             mov    0x30(%rsp),%eax
  4005a0:       44 8b 54 24 28          mov    0x28(%rsp),%r10d
  4005a5:       83 c1 11                add    $0x11,%ecx
  4005a8:       44 8b 5c 24 20          mov    0x20(%rsp),%r11d
  4005ad:       83 c2 11                add    $0x11,%edx
  4005b0:       83 c6 11                add    $0x11,%esi
  4005b3:       83 c7 11                add    $0x11,%edi
  4005b6:       83 c0 11                add    $0x11,%eax
  4005b9:       41 83 c2 11             add    $0x11,%r10d
  4005bd:       41 83 c3 11             add    $0x11,%r11d
  4005c1:       89 44 24 10             mov    %eax,0x10(%rsp)
  4005c5:       44 89 54 24 08          mov    %r10d,0x8(%rsp)
  4005ca:       44 89 1c 24             mov    %r11d,(%rsp)
  4005ce:       e8 0d ff ff ff          callq  4004e0 <kt_func3>
  4005d3:       48 83 c4 18             add    $0x18,%rsp
  4005d7:       c3                      retq

How would you propose recovering the value which was in %r9d on
entrance to this function?  Or %ecx?  It can't be done.  A
too-clever-for-its-own-good compiler might tell us that we could
recreate a read-only copy by unwinding %r9d and then subtracting 0x11,
except that I'm pretty sure the register is call clobbered, so we can't
recreate its value anyway.

-- 
Daniel Jacobowitz
CodeSourcery, LLC