This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Teach i386 prologue reader about _alloca and __main
Mark Kettenis wrote:
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)?
Correct.
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.
Yes, that's why I added it. Humm, I'll have to try it out on
another target to see if its a Cygwin specific gcc problem.
It's probably best to seperate this bit form the __main/_alloca mess.
Will do.
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 can't say I am happy either.
I'll see if I can simplify it a bit, by only caring about -O0.
I did raise it with GCC almost a year ago, in the form of a patch:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html
Got no replies, but then again, I never pinged it.
We have to live with current compilers, though.
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.
Dunno. The MSFT version of __chkstk supposedly compares the amount
of stack space a function requires with the amount the stack space
available, specified in the EXE header, and I guess specified on thread
creation.
http://support.microsoft.com/?scid=kb%3Ben-us%3B100775&x=10&y=10
gcc's version doesn't, so, it looks like work waiting for a volunteer.
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.
Will do. Thanks.
Cheers,
Pedro Alves