This is the mail archive of the
mailing list for the GCC project.
Re: [patches] Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix
>>>>> "Jan" == Jan Hubicka <email@example.com> writes:
>> It can? But the adjustment is emitted immediately after the call, and only
>> calls can throw. Surely the scheduler wouldn't move a stack adjustment
>> past a call?
> This is fragile concept and is broken in my tree already.
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?)
> 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
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.
Do you have patches to make gdb use the info in .eh_frame, then?
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
> 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.