This is the mail archive of the
mailing list for the GCC project.
Re: [patches] Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix
> How is it fragile to assume that the scheduler won't move an SP adustment
> past another instruction that uses SP, such as a call? If that's broken,
> it should be fixed.
> (Calls ARE treated as using SP, right?)
No - fragile is that call.c can get smart and do defering of stack adjustments
for pascal functions like it does for -mno-accumulate-outgoing-args, so when
> > Moreover I need dwarf2 info exact on each instruction boundary - so I need
> > the info inside prologues/epilogues exact as well.
> Why? For use in a debugger, perhaps? This is a larger question. The
For use in debugger and in unwinding library for x86_64. For instance the
garbage collector needs to unwind stack at any point.
> current information is optimized for size, based on the requirements of the
> unwinder (i.e. that the info only needs to be meaningful at call sites).
> My intent is to do further optimization along these lines. Debuggers, of
> course, need more detailed information if we want to be able to unwind from
> an arbitrary point in a function. One solution to this would be to
> optionally emit .debug_frame as well as .eh_frame.
Yep, this may be cool.
> Do you have patches to make gdb use the info in .eh_frame, then?
No - we didn't started GDB yet.
> If this really is a requirement for .debug_frame, then I suppose noting the
> stack adjustment as you suggest makes sense. But it isn't a requirement
> for .eh_frame.
For .eh_frame the current code notices them, remembers and throws away
if no call is in the way.
> > Another manifestation of the problem in current tree can be IMO the fact that
> > -mno-accumulate-outgoing-args makes gcc to notice pushes and emits info
> > to restore global registers, while -maccumulate-outgoings-args omits this.
> I'm sorry, I don't follow. -maccumulate-outgoing-args doesn't notice
> pushes because there shouldn't be any; we should be using the pre-allocated
> space. It does still emit info to restore saved registers, however.
Thats the problem - for i386 there are pushes used in prologue/epilogue
sequences I need to get noticed.