On Jan 16, 2008 4:24 PM, Arun Paneri <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > To: Arun Paneri <[EMAIL PROTECTED]> > Cc: FreeBSD User <[EMAIL PROTECTED]>; firstname.lastname@example.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 > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"