Pls help: regarding gdb internals

[Aryeh Friedman]

On Jan 16, 2008 4:24 PM, Arun Paneri <p26a at yahoo.com> wrote:
> Thanks Aryeh & Chuck.
> Well, I am trying to solve issues related to GDB. Like, gdb prints wrong values of few parameteres eg "this" pointer, when we give "backtrace" or "x/10x $ebp" command in core of our company product.

It should be the first param (i.e. starts on byte 12 of the frame)...
$ebp points the next stack frame (i.e. where the next push will
happen) so to really understand you need to look 12 bytes  "below"
edp... For example I used the following loop to find what func a call
came from (since I  don't have the orginal code any more this is
psedo):

do
     ptr=(*edb) +4  // gives you the return addr for the current frame
while ptr!=desired frame addr

the edb+12 has be done with inline asm

when the loop is done ptr-4 is the start of the frame your intrested
in thus ptr-4+12 is the this param.

A small caution here doing this kind of in stack ptr math can lead to
some very bizzare bugs... for example the above loop combined with a
param ptr deref (i.e. treat the param of intrest as a ptr) lead to the
strangest bug I have seen in my 20 year career... essencially lets say
I had a loop to go through params to see which one of interest (I was
using this as a way of automating some aspects of a OO RDBMS), which
in my case was the first param of a ptr type whose value was -1 [the
db would then do some db magic and replace it with a ptr to a real
instance read from disk]... now that being said lets say "a" is the
offset of the current param and "b" is the offset of current param we
are testing such that:

while(b<param_cnt*4)
      if(a==b&&*b!=-1)
             do something

     b+=4

When we get to the case where the *NEXT* b would be a==b [i.e. the
value *AFTER* the next b+=4] the value of "a" would go completely
insane.... even attempts to avoid equality such as if(a-b) ...
produced the same result... to this day I have not the fuggiest idea
of what caused this and commonly refer to it as the time machine bug.

This plus the complete weirdness of the stabs format is what finally
convienced me to switch to Java as my prefered lang (has reflection
thus no need to dive into the debug symbols and everything inherits
from Object instead of null)

>
> I think it reads wrong value from symbol table or stack frame. So i am trying to put a break point and see what exactly gdb reads for that perticuler frame when it shows a wrong data. But dont know where exactly it reads data from the symbol table or stack frame.
>
> If you have a specific idea regarding this pls give some more info.
>
>
> Regards.
>
>
> ----- Original Message ----
> From: Chuck Swiger <cswiger at mac.com>
> To: Arun Paneri <p26a at yahoo.com>
> Cc: FreeBSD User <freebsd at stigascorp.com>; freebsd-questions at freebsd.org
> Sent: Wednesday, January 16, 2008 2:56:36 PM
> Subject: Re: Pls help: regarding gdb internals
>
> On Jan 16, 2008, at 10:58 AM, Arun Paneri wrote:
> > Can anyone write few lines about how does gdb internally works. I
> > went to "Gdb internals guide" but couldn't find much information
> > specifically which i am looking for.
>
> I'm not familiar with the document you mentioned, but the canonical
> documentation for GDB is available via "info gdb".
>
> > I want information like when we give command "$gdb test.exe" then
> > how internaly it works. Does it start reading symbols and start
> > making symbol table with this command?
>
> Binary objects such as executable programs, shared libraries, etc
> contain symbol tables; GDB does a quick load of this symbol data to
> identify all of the sources of symbols for the program, and then will
> look up the details when needed.
>
> > Does it start creating stack frames as we give command "run" or
> > before even that?
>
> The program being debugged does not exist as a process until you run
> it, so there isn't an address space or stack until then.  When the
> target program is run, it creates it's own stack frames according to
> the local architecture's machine calling conventions.
>
> > I am basically interested to know about creation of frames and how
> > does gdb read them back when we give "backtrace" command?
>
> Well, the calling conventions are different for every particular CPU
> architecture; but if you want to see the code that GDB uses, start with:
>
> /usr/src/contrib/gdb/gdb/frame-base.c
> /usr/src/contrib/gdb/gdb/frame-base.h
> /usr/src/contrib/gdb/gdb/frame-unwind.c
> /usr/src/contrib/gdb/gdb/frame-unwind.h
> /usr/src/contrib/gdb/gdb/frame.c
> /usr/src/contrib/gdb/gdb/frame.h
>
> ...but I suspect that something like these two articles are closer to
> what you are looking for:
>
> http://en.wikipedia.org/wiki/Calling_convention
> http://en.wikipedia.org/wiki/X86_calling_conventions
>
> --
> -Chuck
>
>
>       ____________________________________________________________________________________
>
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>