Re: [rfc] Teach i386 prologue reader about _alloca and __main

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Sat, 13 Oct 2007 20:54:45 +0100
> From: Pedro Alves <pedro_alves@portugalmail.pt>
> 
> Hi guys,
> 
> This is a new take on solving the issue described here:
> 
> http://www.sourceware.org/ml/gdb/2006-11/msg00140.html
> 
> On a nutshell, breaking on main is broken on Cygwin, and
> all targets where gcc emits a call to __main in main,
> right after the prologue.  __main is responsible for calling
> the c++ constructors of global objects, and registering the
> destructors of the same objects to run at exit.  This call
> is inserted on targets that don't have an .init section.

Do I understand correctly that this is not really Cygwin specific, but
done for all targets with executable formats that don't have a concept
of constructors (like ELF with .init)?

> There is another problem with the prologue analysing, which is visible
> on i386 targets using stabs debug info on gcc >= 4.1.0.
> 
> eg:
> int main (int argc, char **argv)
> {
> 
> On stabs, the debugger only knows that argc is the first parameter to
> the function and that its type is int.  It is up to the debugger
> to know how to extract it from the frame.
>
> Gcc >= 4.1 can put code in the prologue to realign the stack pointer.
> In that case, the frame base will not be the same as the incoming args
> address, so gdb prints garbage for the arguments:
> 
> main (argc=2280856, argv=0x61006198) at main.c:8

This is why you added i386_frame_args_address() isn't it?  I thought
GCC would actually copy the arguments in that case, but apperently
that doesn't happen (anymore).  Perhaps I'm just mistaken though.

It's probably best to seperate this bit form the __main/_alloca mess.

> The __main call is only expected on targets that gdb knows it should
> be there.  A new gdbarch callback is introduced for it, and cygwin
> registers it.

Like Daniel said already, unless you expect this gdbarch callback to
be necessary on other architectures besides i386/amd64 it's better to
make this a function pointer in 'struct i386_tdep'.

> The patch intruduces a few minsyms lookups, which I'm not sure we
> can do without.  It looks like the risk is high to get it wrong
> otherwise.

As long as they only happen on platforms that suffer from __main I
don't care ;).

> Comments?

I'm not too happy about this.  It adds a lot of complexity for
something I think the compiler should emit proper debug information
for.  Did you raise the issue with the GCC people?  What was their
answer?

I think the alloca analysis should only happen on targets that need
it.  I wonder why GCC needs to make a library call, where it seems
simply touching every page would be enough.

Also, in i386_frame_cache(), I'd make the comment about where to
finding %ecx a bit more general.  I can think of other reasons why
that register might have been pushed onto the stack.  Might as well
seperate out that bit from the diff too.