* Add frame_is_callee_p(), use in dwarf2-frame.c?
@ 2003-07-02 18:47 Andrew Cagney
2003-07-02 19:12 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-07-02 18:47 UTC (permalink / raw)
To: gdb-patches
Hello,
Following up the comment:
> /* Unwind the PC.
>
> Note that if NEXT_FRAME is never supposed to return (i.e. a call
> to abort), the compiler might optimize away the instruction at
> NEXT_FRAME's return address. As a result the return address will
> point at some random instruction, and the CFI for that
> instruction is probably wortless to us. GCC's unwinder solves
> this problem by substracting 1 from the return address to get an
> address in the middle of a presumed call instruction (or the
> instruction in the associated delay slot). This should only be
> done for "normal" frames and not for resume-type frames (signal
> handlers, sentinel frames, dummy frames).
>
> We don't do what GCC's does here (yet). It's not clear how
> reliable the method is. There's also a problem with finding the
> right FDE; see the comment in dwarf_frame_p. If dwarf_frame_p
> selected this frame unwinder because it found the FDE for the
> next function, using the adjusted return address might not yield
> a FDE at all. The problem isn't specific to DWARF CFI; other
> unwinders loose in similar ways. Therefore it's probably
> acceptable to leave things slightly broken for now. */
> fs->pc = frame_pc_unwind (next_frame);
Given MichaelC's flurry of bugs on this, should the fix be added to 6?
As for the dwarf2_frame_p test, outch! Any ideas? Change the parameter
to ``address_in_block'', instead of a PC?
Regardless, for a ``normal frame'' test, I'd like to suggest
``frame_is_callee_p()'' as something suitable descriptive. Thoughts?
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add frame_is_callee_p(), use in dwarf2-frame.c?
2003-07-02 18:47 Add frame_is_callee_p(), use in dwarf2-frame.c? Andrew Cagney
@ 2003-07-02 19:12 ` Daniel Jacobowitz
2003-07-02 19:28 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-07-02 19:12 UTC (permalink / raw)
To: gdb-patches
On Wed, Jul 02, 2003 at 02:47:11PM -0400, Andrew Cagney wrote:
> Hello,
>
> Following up the comment:
>
> > /* Unwind the PC.
> >
> > Note that if NEXT_FRAME is never supposed to return (i.e. a call
> > to abort), the compiler might optimize away the instruction at
> > NEXT_FRAME's return address. As a result the return address will
> > point at some random instruction, and the CFI for that
> > instruction is probably wortless to us. GCC's unwinder solves
> > this problem by substracting 1 from the return address to get an
> > address in the middle of a presumed call instruction (or the
> > instruction in the associated delay slot). This should only be
> > done for "normal" frames and not for resume-type frames (signal
> > handlers, sentinel frames, dummy frames).
> >
> > We don't do what GCC's does here (yet). It's not clear how
> > reliable the method is. There's also a problem with finding the
> > right FDE; see the comment in dwarf_frame_p. If dwarf_frame_p
> > selected this frame unwinder because it found the FDE for the
> > next function, using the adjusted return address might not yield
> > a FDE at all. The problem isn't specific to DWARF CFI; other
> > unwinders loose in similar ways. Therefore it's probably
> > acceptable to leave things slightly broken for now. */
> > fs->pc = frame_pc_unwind (next_frame);
>
>
> Given MichaelC's flurry of bugs on this, should the fix be added to 6?
>
> As for the dwarf2_frame_p test, outch! Any ideas? Change the parameter
> to ``address_in_block'', instead of a PC?
That sounds reasonable...
> Regardless, for a ``normal frame'' test, I'd like to suggest
> ``frame_is_callee_p()'' as something suitable descriptive. Thoughts?
You've leapt ahead of me again. What would frame_is_callee_p mean?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add frame_is_callee_p(), use in dwarf2-frame.c?
2003-07-02 19:12 ` Daniel Jacobowitz
@ 2003-07-02 19:28 ` Andrew Cagney
2003-07-02 19:36 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2003-07-02 19:28 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> Regardless, for a ``normal frame'' test, I'd like to suggest
>> ``frame_is_callee_p()'' as something suitable descriptive. Thoughts?
>
>
> You've leapt ahead of me again. What would frame_is_callee_p mean?
The frame is a callee, it has a caller with a call instruction?
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add frame_is_callee_p(), use in dwarf2-frame.c?
2003-07-02 19:28 ` Andrew Cagney
@ 2003-07-02 19:36 ` Daniel Jacobowitz
2003-07-03 16:18 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-07-02 19:36 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
On Wed, Jul 02, 2003 at 03:28:50PM -0400, Andrew Cagney wrote:
> >Regardless, for a ``normal frame'' test, I'd like to suggest
> >>``frame_is_callee_p()'' as something suitable descriptive. Thoughts?
> >
> >
> >You've leapt ahead of me again. What would frame_is_callee_p mean?
>
> The frame is a callee, it has a caller with a call instruction?
Oh, makes sense to me.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add frame_is_callee_p(), use in dwarf2-frame.c?
2003-07-02 19:36 ` Daniel Jacobowitz
@ 2003-07-03 16:18 ` Andrew Cagney
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2003-07-03 16:18 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> On Wed, Jul 02, 2003 at 03:28:50PM -0400, Andrew Cagney wrote:
>
>> >Regardless, for a ``normal frame'' test, I'd like to suggest
>
>> >>``frame_is_callee_p()'' as something suitable descriptive. Thoughts?
>
>> >
>> >
>> >You've leapt ahead of me again. What would frame_is_callee_p mean?
>
>>
>> The frame is a callee, it has a caller with a call instruction?
>
>
> Oh, makes sense to me.
But if you can think of a better name :-)
The flip side would be to try something like ``frame is interrupt'' or
`frame unwind is correct'', but then that gets into refinements like
``frame might be correct because of decr pc after break'' ....
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add frame_is_callee_p(), use in dwarf2-frame.c?
@ 2003-07-02 19:14 Michael Elizabeth Chastain
0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-02 19:14 UTC (permalink / raw)
To: ac131313, gdb-patches
> Given MichaelC's flurry of bugs on this, should the fix be added to 6?
I'd love it! Right now that's my only big regression whine.
If you indicate which of the flurry of patches to test, I can throw them
on my test bed right now.
Michael C
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-07-03 16:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-02 18:47 Add frame_is_callee_p(), use in dwarf2-frame.c? Andrew Cagney
2003-07-02 19:12 ` Daniel Jacobowitz
2003-07-02 19:28 ` Andrew Cagney
2003-07-02 19:36 ` Daniel Jacobowitz
2003-07-03 16:18 ` Andrew Cagney
2003-07-02 19:14 Michael Elizabeth Chastain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox