Re: HEADS UP: converting the i386 to the new frame unwinding stuff

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Joel Brobecker]

> However, Interix will need some serious work.  The frame methods it
> redefines will have to be replaced by *_frame_pc_unwind and
> *_frame_id_unwind functions.  Should I leave that to you Joel, or
> would you like me to write some initial versions and leave the
> necessary testing and bug-fixing to you?

If you have a rough idea of what the code should look like and you have
the time to write them, then that would be very helpful. Otherwise, it's
fine to leave this to me.

-- 
Joel

HEADS UP: converting the i386 to the new frame unwinding stuff

[Mark Kettenis]

Folks,

I've been working on making the i386 target use the new frame
unwinding stuff.  I'm at a stage where I'm seeing no regressions on
i386-unknown-freebsd4.7.  So I'd like to check my work in, in the not
too distant future.  However, this is probably going to cause some
fallout amongst the other targets.

As far as I can see *BSD, GNU/Linux, GNU/Hurd, the various System
V-derived systems (including Solaris 2.x), Netware, DJGPP, Cygwin, and
the various embedded targets should be fine.

My changes will break the various Sequent Symmetry targets, and I'll
probably leave them broken (which they probably already are).

I'll see whether I can fix LynxOS before actually committing the
patch.

However, Interix will need some serious work.  The frame methods it
redefines will have to be replaced by *_frame_pc_unwind and
*_frame_id_unwind functions.  Should I leave that to you Joel, or
would you like me to write some initial versions and leave the
necessary testing and bug-fixing to you?

Mark

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Michal Ludvig]

Mark Kettenis wrote:
> I've been working on making the i386 target use the new frame
> unwinding stuff.  I'm at a stage where I'm seeing no regressions on
> i386-unknown-freebsd4.7.  So I'd like to check my work in, in the not
> too distant future.  However, this is probably going to cause some
> fallout amongst the other targets.

I'm going to do the same for x86-64 - could you send me your patches yet 
before committing for "inspiration"? :-))
BTW Do you already use dwarf2cfi stuff for i386?

Thanks,
Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Andrew Cagney]

> Folks,
> 
> I've been working on making the i386 target use the new frame
> unwinding stuff.  I'm at a stage where I'm seeing no regressions on
> i386-unknown-freebsd4.7.  So I'd like to check my work in, in the not
> too distant future.  However, this is probably going to cause some
> fallout amongst the other targets.
> 
> As far as I can see *BSD, GNU/Linux, GNU/Hurd, the various System
> V-derived systems (including Solaris 2.x), Netware, DJGPP, Cygwin, and
> the various embedded targets should be fine.
> 
> My changes will break the various Sequent Symmetry targets, and I'll
> probably leave them broken (which they probably already are).
> 
> I'll see whether I can fix LynxOS before actually committing the
> patch.
> 
> However, Interix will need some serious work.  The frame methods it
> redefines will have to be replaced by *_frame_pc_unwind and
> *_frame_id_unwind functions.  Should I leave that to you Joel, or
> would you like me to write some initial versions and leave the
> necessary testing and bug-fixing to you?

Mark,

Per several recent discussions, can you create a branch and commit it to 
that.  That way I can look at it now (regardless of your intended commit 
schedule)?

I've started writing up the doco and in doing it, I suspect I may have 
found an `off by one' error with the unwinder cache.  Having a second 
implementation using the current code should help sort this out.

Andrew

(1) The best way of explaining the problem is to document how things work.

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Mark Kettenis]

   Date: Mon, 03 Mar 2003 13:45:41 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   Mark,

   Per several recent discussions, can you create a branch and commit it to 
   that.  That way I can look at it now (regardless of your intended commit 
   schedule)?

Brilliant idea.  I still have to comment my code a bit better, but
I'll try to create that branch somehwere at the end of the week.

   I've started writing up the doco and in doing it, I suspect I may have 
   found an `off by one' error with the unwinder cache.  Having a second 
   implementation using the current code should help sort this out.

The current state of affairs seems to work quite well for the i386.
The only thing that puzzles me is that apparently my
i386_frame_register_unwind gets called without an initialized cache.
I was under the impression that we'd always unwind the pc first, and
since my i386_frame_pc_unwind initialized the cache, I'd always have
an initialized cache with the other unwind functions.

Mark

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Andrew Cagney]

>    Date: Mon, 03 Mar 2003 13:45:41 -0500
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    Mark,
> 
>    Per several recent discussions, can you create a branch and commit it to 
>    that.  That way I can look at it now (regardless of your intended commit 
>    schedule)?
> 
> Brilliant idea.  I still have to comment my code a bit better, but
> I'll try to create that branch somehwere at the end of the week.
> 
>    I've started writing up the doco and in doing it, I suspect I may have 
>    found an `off by one' error with the unwinder cache.  Having a second 
>    implementation using the current code should help sort this out.
> 
> The current state of affairs seems to work quite well for the i386.
> The only thing that puzzles me is that apparently my
> i386_frame_register_unwind gets called without an initialized cache.
> I was under the impression that we'd always unwind the pc first, and
> since my i386_frame_pc_unwind initialized the cache, I'd always have
> an initialized cache with the other unwind functions.

I think you just hit my off-by-one bug.  While I've got get_prev_frame() 
doing the sequence:

	prev_frame->pc = frame_pc_unwind(next_frame)
	..
	prev_frame->id = frame_id_unwind(next_frame)

To determine prev_frame's id, prev_frame's prolog needs to have been 
analyzed.  Contrast that to pc-unwind and register-unwind where the 
unwound register value is determined by analyzing next_frame's prologue. 
  The off by one is that frame id unwind is being handed the wrong cache 
:-(  (in my defence, I've preserved existing behavour just a bit too 
well - explains why the d10v was to easy to convert :-/)

Andrew


	

Re: HEADS UP: converting the i386 to the new frame unwinding stuff

[Andrew Cagney]

>> The current state of affairs seems to work quite well for the i386.
>> The only thing that puzzles me is that apparently my
>> i386_frame_register_unwind gets called without an initialized cache.
>> I was under the impression that we'd always unwind the pc first, and
>> since my i386_frame_pc_unwind initialized the cache, I'd always have
>> an initialized cache with the other unwind functions.

> 
> I think you just hit my off-by-one bug. 

Mark, FYI.  I've committed an 80% finished fix to the problem to the 
cagney_offbyone-20030303-branch (80% to go).  You could always commit 
your changes to that branch (but don't expect them to work).

Andrew