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

[Pedro Alves <pedro_alves@portugalmail.pt>]

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