Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Tigran Aivazian <tigran@veritas.com>
To: gdb@sources.redhat.com
Subject: gdb problems with -O1 on x86_64 architecture.
Date: Mon, 09 May 2005 16:17:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.61.0505091703140.4462@ezer.homenet> (raw)

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;
}


             reply	other threads:[~2005-05-09 16:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09 16:17 Tigran Aivazian [this message]
2005-05-09 16:39 ` Daniel Jacobowitz
2005-05-09 16:47   ` Tigran Aivazian
2005-05-10 14:32     ` Tigran Aivazian
2005-05-10 14:45       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0505091703140.4462@ezer.homenet \
    --to=tigran@veritas.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox