This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb says EVERY argument or variable is optimized out (Re: gdb and fission scheme (gcc: -gsplit-dwarf, gnu ld gold :--gdb-index ))


Hi,

Several months ago, I posted a report of my final success of
debugging a relatively large program mozilla's thunderbird mailer using
gcc's -gsplit-dwarf and gnu ld.

Well, I have been able to set break point on functions and lines, and so
far so good.

My setup : x86_64  Debian GNU/Linux
GNU GNU gold (GNU Binutils 2.25.51.20141027) 1.11
gdb (Debian 7.7.1+dfsg-5) 7.7.1

However, I was troubled that no argument values could be printed
in the stack trace
because they are "optimized out" according to gdb.
This was from past summer, and I thought maybe the GCC compiler's
optimization became rather good and confused gdb.

However, for debugging particular class of bugs,
I really needed to print some values on the stack trace when a
breakpoint is hit, as well as local variables manually.
So I made sure that I passed -O instead of higher optimization.

But GDB still could not see the variable values, and I was very confused.
I even went on to dump .o and .dwo files to learn there does
seem to be the location of the argument in dwarf information. However, I
am no expert of gcc and gdb and could not tell if the location
information is in correct format or not although
it seems to indicate that the location of the argument(s) was in
register(s) since it is on x86_64 [calling convention uses a few
registers and then stack.]
(Gee, I forgot exactly how I did that. I think I dumped the dwarf
information and saw some kind of RTL like description of the location or
something....)

I searched WWW if anyone had a similar experience of gdb telling that
every argument passed to a function is "optimized out" and found

https://code.google.com/p/chromium/issues/detail?id=439320

who reported a similar issue in December.
In the above report, it was pointed out there could be a few issues: one
is that during linking the debug information is transformed, etc.

The reporter said that disabling -gsplit-dwarf cured the problem.
So it seems that using Dwarf Fission scheme and gnu ld and gdb does not
mix well.

In my case, disabling -gsplit-dwarf means a very long time (several
minutes) of I/O during linking process alone and this is unacceptable
overhead for interactive debugging after changing a single C++ source file.

With -gsplit-dwarf, compile and link is somewhere below 2 minutes. This
is more or less acceptable.

I wonder if this failure of gdb to report the value of
variable when -gsplit-dwarf is used is a known problem and there is a
fix for this.

Testing with a very simple program consisting of
two files quoted below shows that a simple case like this would work.
So as was pointed out in the above URL's report, maybe something gets
broken during linking?
Or maybe the buggy symptom appears only when the binary size becomes
very large and the total size of library if statically linked goes over
close to 2GB or something.
Thunderbird cannot be linked using ordinary ld with full debug symbol
in 32-bit linux because the linker runs out of address space.
That is the order of the size I am talking about.


TIA

--- sample test program
test-main.cpp:
void
test_symbol(int argc, char *ap[]);

char *test_index[2] = {
  "abcde",
  "xyz"
};

int
main() {
  test_symbol(10, test_index);
  return 0;
}


test-symbol.cpp:
#include <stdio.h>

void
test_symbol(int argc, char *ap[]) {

  printf("argc = %d\n", argc);
  printf("ap[0]=%s\n", ap[0]);
  return;
}

====
gdb can print argument value works
This is with -gsplit-dwarf compilation
but no link-time optimization.
====
ishikawa@ip030:/REF-COMM-CENTRAL/work-dir$ gdb test-main
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.

[... omission ...]

Type "apropos word" to search for commands related to "word"...
Reading symbols from test-main...done.
(gdb) break test_symbol
Breakpoint 1 at 0x4005c3: file test-symbol.cpp, line 4.
(gdb) run
Starting program: /REF-COMM-CENTRAL/work-dir/test-main

Breakpoint 1, test_symbol (argc=argc@entry=10,
    ap=ap@entry=0x401a00 <test_index>) at test-symbol.cpp:4
warning: Source file is more recent than executable.
4	test_symbol(int argc, char *ap[]) {
(gdb) print argc
$1 = 10
(gdb) print ap
$2 = (char **) 0x401a00 <test_index>
(gdb) print *ap
$3 = 0x400674 "abcde"
(gdb) quit

With thunderbird binary, I can't print variable or argument
since gdb says "optimized out" for EVERY variable/argument :-(


PS: Because I could not print argument values, I was forced to check for
registers where the argument seems to be passed (on X86_64).
But it becomes much harder on X86 architecture since the argument is
passed on the stack. Calculating the position of variable on the stack
is rather difficult and  setting conditional breakpoint based on
argument value was next to impossible. (Oh, well, there must be a way,
but I am not sure how to do it. Trying to reference register value and
use it in a meaningful manner to refer to the variable on the stack was
tricky. I seemed to have generated a syntax error in the expression,
which resulted in segmentation error somewhere...)
Well, this is not source-level debugging :-)



On 2014/03/25 14:35, ishikawa wrote:
> (I tried to send to gdb mailing list and Doug, but I am afraid
> my inclusion of too many lines from previous e-mails made
> the mailing list software to think the post was a spam.
> So I am reposting this with some editorial changes for clarification and
> including only about a dozen lines from the previous e-mails, and making it
> much shorter.)
> 
> Hi,
> 
> It has been a while since I last posted to gdb mailing list asking for
> help using -gsplit-dwarf flag to gcc and then
> use gdb to debug a very complex program, mozilla's thunderbird
> mail client, which has many source files scattered all over a large source tree.
> 
> Back when I posted the question,
> I could not get gdb to grok the thunderbird-bin binary after
> it is compiled with -gsplit-dwarf is given to gcc 4.8.x.
> 

> It turns out the modified version of ccache, which supports -gsplit-dwarf,
> which I use to
> save compile time when a set of local patch is frequently applied and
> backed out was one cause of the problem.
> With Doug's suggestion, I have continued tinkering with
> the ccache and -gsplit-dwarf, ld.gold, and dwp that is in git head of
> binutils source repository.
> 
> Once the unofficial version of ccache was fixed to correctly use a permanent
> file pathname for .dwo file and embed it in the object file (simply by
> specifying
> the permanent object filename via -o inside ccache, GCC takes care of the
> rest), I could
> make gdb to grok the thunderbird-bin (!).
> It no longer complains CU not found anywhere.
> 
> Encouraged, I went on, and after I placed
> set debug-file-directory dir1:dir2:...:dirN
> (where dir1, dir2, ..., dirN
> are the directories where .dwo files are created during thunderbird
> compilation, about 400- of them! Certainly a long command line.)
> in .gdbinit,
> I could finally set breakpoint properly in the function
> not loaded at the gdb's invocation, and when the control reaches it,
> gdb prompt appears and  |bt|, |where|, |list|, etc.
> work as expected (!)
> 
> Thank you again for the helpful tips.
> 
> Chiaki
> 
> 
>> (2013/09/27 10:31), ISHIKAWA,chiaki wrote:
>>     (2013/09/27 3:49), Doug Evans wrote:
>>         On Sat, Sep 21, 2013 at 7:29 PM, ISHIKAWA,chiaki
> <ishikawa@yk.rim.or.jp> wrote:
>>
>>             I have investigated a little further. Now it has dawned on me
>> that using "-gsplit-dwarf" binaries for debugigng is not a simple
>> plug-and-play in contrast to ordinary dwarf binaries where debug information
>> for a source module is in the single .o file and linker consolidates the
>> information into a single final binary.
>>
>>         Hi. You surmise correctly.
> 
> [Somehow, smiley at the end of  Doug's first line could not be copy-pasted.
> The rest of the quote is omitted.]
> 
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]