This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: The gdb x86 function prologue parser


   From: Jason Molenda <jmolenda@apple.com>
   Date: Mon, 13 Jun 2005 15:04:51 -0700

   Hi Mark,

   On Jun 12, 2005, at 12:07 AM, Mark Kettenis wrote:

   > Sorry I didn't reply before; I still was on vacation when you sent out
   > this mail.

   Not at all.  Thanks for taking the time to look at it.

   > Another question that I have is what calling convention MacOS X will
   > use.  Is it something like the System V ABI where the caller is
   > supposed to clean up the stack after a function call?

   It's the System V IA-32 ABI except that small structs are returned in  
   registers, stack frames are 16-byte aligned, and large types are kept  
   at their natural alignment.  We haven't officially finalized our x86  
   ABI yet, so it's possible we'll tweak it a bit before we're done.   
   But it's a safe bet that any changes will be minor variations from  
   the SysV IA32 ABI.

Great, that's rather similar to what OpenBSD and FreeBSD do.

   > It's no surprise to
   > me though that the prologue scanner appears a bit weak to you though.
   > It started out as a prologue scanner for the origional System V
   > compiler with some additions to older GCC versions when I took over.
   > At that point, GCC still had a fixed prologue.  When GCC 3.x started
   > scheduling prologue instructions, it also started generating usable
   > DWARF CFI, so whe took the conscious decision to rely on that and only
   > improve the prologue scanner on an as-needed basis.  Since GCC 3.x
   > targets for all major free OS'es all use DWARF by default, this means
   > that the prologue scanner really only handles some bits of
   > hand-optimized assembler.


   Ah!  Now it starts to make sense.  I couldn't understand how this had  
   been so untested. :)

   The one part I'm curious about -- does gdb get the CFI information  
   out of gcc's eh_frame section or something?  How do developers debug  
   KDE/GNOME applications, where many functions on their stack are from  
   optimized libraries that don't have any debug info (except maybe  
   eh_frame)?  It seems like these users should be tripping on these  
   problems all the time.

Yup.  We prefer .debug_frame but if that's not available we suck in
.eh_frame.  So anything that's compiled with -fexceptions (wich
implies all C++ code) basically has usable CFI.

   > Well, it handles most of the frameless functions encountered on a
   > GNU/Linux system with GCC 3.2 fine.

   I tested the patch on a FedoraCore 2 system -- I have no idea which  
   compiler was used to build the system, but I'd guess it's gcc 3.2 or  
   3.3

Hell, it's probably a heavily snapshot of something in between.  I've
mostly given up on Linux, because everyone seems to want to have the
latest bugs over there ;-).

   Breakpoint 2, 0x00a3b9aa in htmlDefaultSAXHandlerInit ()
       from /usr/lib/libxml.so.1
   (gdb) bt
   #0  0x00a3b9aa in htmlDefaultSAXHandlerInit () from /usr/lib/libxml.so.1
   #1  0xfef1ecf8 in ?? ()
   #2  0x080485c3 in foo () at /tmp/a.c:10
   Previous frame identical to this frame (corrupt stack?)
   (gdb)


   It might seem like I'm being mean and picking the one routine that  
   fails, but no, this idiom is used in many places and gcc often  
   schedules it right into the prologue.  It's a system library, so  
   there's no debug info to help you out.

   I honestly think that gdb users are hitting this a lot more often  
   than you'd think, but aren't reporting it.

I sometimes wonder whether people are using gdb at all...

...then I find it incredibly stupid that vendors of an Open Source
operating system ship libraries without debugging information.

   > And no, assuming that a function
   > has set up a stack frame isn't right; it makes gdb silently skip
   > function calls in backtraces.  That can be very confusing.

   On 0th frame, you're right, it's wrong to assume that the function  
   sets up a stack frame.  But when you're off the 0th frame (and the  
   next_frame isn't a signal trampoline or gdb dummy frame, etc.), the  
   function set up a stack frame (assuming -fomit-frame-pointer codegen  
   wasn't used, in which case we're in real trouble ;).  If we fail to  
   parse the prologue instructions in that function, we should assume  
   what must be the case - that it set up a stack frame.

I'm fairly sure I've seen cases that I've seen GCC generate frameless
functions even without -fomit-frame-pointer.

   > Great.  I haven't looked at your patch in detail yet.  But it sounds
   > like some of the improvements can be made right away, so let's get
   > working on this ;-).

   Yeah, I need to integrate the feedback I received last week from  
   Daniel and Eli -- lose inttypes.h, use the opcodes instruction parser  
   instead of doing it myself -- so I'll get that stuff wrapped up and  
   post an updated patch soon.

Looking forward to it.

Mark


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