public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: asmwarrior <asmwarrior@gmail.com>
To: gdb@sourceware.org
Subject: About the "info locals" command of gdb and python pretty printer
Date: Sun, 20 Jun 2010 09:13:00 -0000	[thread overview]
Message-ID: <4C1DDBB0.9010202@gmail.com> (raw)

Hi, I have some problems to show some uninitialized local variables.

For example, here is the test code:

void test()
{
     int aaaa = 1;
     int bbbb = 2;
     int cccc = 3;
}

int main()
{
     test();
     return 0;
}

Here, if I set a breakpoint at the first statement of the "test()", then 
run "info locals" command. gdb will plot all the information about both 
"aaaa, bbbb and cccc".

Things becomes more complex when bbbb and cccc are not simple type, but 
instead, they are stl containers like vector<int> or maps.
like:

void test()
{
     int aaaa = 1;
     vector <int> bbbb;
     map<int,string>cccc;
}

At this time, if we run the "info locals" with python stl pretty printer 
enabled, as you see, if you breakpoint is still at the first line "int 
aaa = 1;", then bbbb and cccc are not initialized, this may cause the 
python script to plot random values, some times, gdb or python will get 
crashed.
A more detailed discussion can be found :
http://sourceware.org/bugzilla/show_bug.cgi?id=11407

Also, this kind of problem is exist some other situations, In the 
QTCreator's manual:
http://doc.qt.nokia.com/qtcreator-1.2/creator-debugging.html
> The debug information provided by gcc does not include enough 
> information about the time when a variable is initialized. Therefore, 
> Qt Creator can not tell whether the contents of a local variable 
> contains "real data", or "initial noise". If a QObject appears 
> uninitialized, its value will be reported as "out of scope". However, 
> not all uninitialized objects can be recognized as such.

I asked this kind of question on the GCC maillist, some one replies in 
this post:
http://gcc.gnu.org/ml/gcc/2010-06/msg00633.html
He suggest that we can use the GCC option: -fvar-tracking

With this option, the variable location was recorded in the output file. 
I have just do a test on my first example code. (I tested under MinGW 
GCC 4.4.4)

objdump -W MyTarget.exe >> log.txt
will give all the debug information, like below:

-----------------------------------
...
<1><5f>: Abbrev Number: 2 (DW_TAG_subprogram)
<60>   DW_AT_external    : 1
<61>   DW_AT_name        : test
<66>   DW_AT_decl_file   : 1
<67>   DW_AT_decl_line   : 1
<68>   DW_AT_MIPS_linkage_name: _Z4testv
<71>   DW_AT_low_pc      : 0x4013d0
<75>   DW_AT_high_pc     : 0x4013ed
<79>   DW_AT_frame_base  : 0x0    (location list)
<7d>   DW_AT_sibling     : <0xb9>
<2><81>: Abbrev Number: 3 (DW_TAG_lexical_block)
<82>   DW_AT_low_pc      : 0x4013d6
<86>   DW_AT_high_pc     : 0x4013eb
<3><8a>: Abbrev Number: 4 (DW_TAG_variable)
<8b>   DW_AT_name        : aaaa
<90>   DW_AT_decl_file   : 1
<91>   DW_AT_decl_line   : 3
<92>   DW_AT_type        : <0xb9>
<96>   DW_AT_location    : 2 byte block: 75 74     (DW_OP_breg5: -12)
<3><99>: Abbrev Number: 4 (DW_TAG_variable)
<9a>   DW_AT_name        : bbbb
<9f>   DW_AT_decl_file   : 1
<a0>   DW_AT_decl_line   : 4
<a1>   DW_AT_type        : <0xb9>
<a5>   DW_AT_location    : 2 byte block: 75 78     (DW_OP_breg5: -8)
<3><a8>: Abbrev Number: 4 (DW_TAG_variable)
<a9>   DW_AT_name        : cccc
<ae>   DW_AT_decl_file   : 1
<af>   DW_AT_decl_line   : 5
<b0>   DW_AT_type        : <0xb9>
<b4>   DW_AT_location    : 2 byte block: 75 7c     (DW_OP_breg5: -4)
<1><b9>: Abbrev Number: 5 (DW_TAG_base_type)
<ba>   DW_AT_byte_size   : 4
<bb>   DW_AT_encoding    : 5    (signed)
<bc>   DW_AT_name        : int
...
----------------------------------------
So, you can see, there are some information about "DW_AT_decl_line", 
this information tells us that this variable is initialized after this 
line.

So, I think if GCC can use this information, then we can nicely solved 
the "info locals" command problem.

Any ideas?

By the way, there are other ways to give the "DW_AT_start_scope" 
information about a variable, but Currently, GCC don't have this kind of 
debug information generated. See here: 
http://gcc.gnu.org/ml/gcc/2007-04/msg00138.html


Thanks for reading my post.

asmwarrior ollydbg from codeblocks' forum


             reply	other threads:[~2010-06-20  9:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-20  9:13 asmwarrior [this message]
2010-06-21  7:48 ` André Pönitz
2010-06-21 20:08 ` Tom Tromey
2010-06-22  0:29   ` asmwarrior
2010-06-22  2:18     ` Tom Tromey
2010-06-23 12:30   ` asmwarrior
     [not found]   ` <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>
2010-06-23 20:28     ` Tom Tromey
2010-06-24  1:16       ` asmwarrior
2010-07-02 10:57       ` Matthias Klose
2010-06-21  3:02 asmwarrior

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=4C1DDBB0.9010202@gmail.com \
    --to=asmwarrior@gmail.com \
    --cc=gdb@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).