Re: [RFA] Artifical dwarf2 debug info

[Andrew Cagney <ac131313@redhat.com>]

>> >If I'm scanning this code correctly, all we would need to do would be
>> >to connect set_unwind_by_pc to the CFI machinery.  No, it's more
>> >complicated than that, we still call both FRAME_CHAIN and frame_pc_unwind;
>> >I'm not entirely clear on how frame_saved_regs_id_unwind works. 
>> >Similarly in get_prev_frame.
> 
>> 
>> FRAME_CHAIN is going away.
>> 
>> The steps are broadly:
>> 	pc = pc-unwind (next_frame)
>> 	if (not an edge case like dummy frame where the id doesn't need to 
>> 	be unwound because the frame can be identified using the callee's ID)
>> 	  id = id-unwind (next_frame);
>> 	create frame from pc/id setting new unwind methods using pc.
>> (frame_saved_regs_id_unwind is there to keep code that just implements 
>> frame chain working.).
> 
> 
> Great!
> 
> 
>> >But what I'd like to see is something like you've sketched above. 
>> >Probably check first for dummy frame, then for sigtramp frame, then for
>> >CFI frame, and then fall back to the defaults.
> 
>> 
>> Yes.  Should the choices/order be hardwired or specified by the 
>> architecture though?  I.e., iterate over a list of possible frames that 
>> are specified by the architecture.
> 
> 
> Hmm, I'm not sure.  Do we have any architectures that would want to
> specify their own frame types?  In such a way that using this CFI
> approach wouldn't suffice?

Well, I'd not want to be the one enabling CFI on all architectures. 
That code needs some serious cleanups.

As for own frame types, a SIGTRAMP frames are one case.


>> The catch is that it needs to unwind the PC before anything else.  That 
>> way it can correctly set the type.  Like I said, patch for that pending.
> 
> 
> Right.  I really appreciate all your cleanups in this area.  I have
> some work to do on FRAME_CHAIN_VALID but I'll sit on it for a while,
> until I see what this looks like when you're done revamping the
> unwinders.  (That's the backtrace-to-or-through-main conversation from
> some months ago.)
> 
> Back to the patch at the beginning of this thread - do you think this
> view of fake CFI information is feasible?  Any comments on Michal's
> patch?

It's feasible.  It may long term solve another problem.  Apparently GDB 
needs to generate, at run time, debug info for things like Java.  It may 
also be easier to handle this case by implementing direct functions and 
not going via CFI.

That actual code, though, is a mess.  It is adding another edge case to 
code that shouldn't have to handle anything at all.

BTW, exactly is the difference between a prologueless and frameless 
function?  The prologue case appears to be checking for a push -> the 
reverse of frameless.

Andrew