Re: IBM S/390 prologue analysis revisited

Re: IBM S/390 prologue analysis revisited

[Elena Zannoni]

Kevin Buettner writes:
 > On Jun 30,  6:22pm, Jim Blandy wrote:
 > 
 > > So, how do you folks feel the balance falls?
 > 
 > I'd like to see your patch go in, if for no other reason than that
 > it'll help provide better backtraces for executables which lack
 > debugging information.  (DWARF CFI won't always be available,
 > will it?)
 > 

yeah, I agree.

 > Also, I happen to think that the implementation is pretty cool and I
 > think it'd be worth having around as a good example of how to
 > implement a prologue analyzer.
 > 

yes, please

elena


 > Kevin

Re: IBM S/390 prologue analysis revisited

[Andrew Cagney]

> I'd like to revisit the question of how to proceed with the s390 frame
> unwinding / prologue analysis code.  I'd like to commit my prologue
> analysis changes, but the IBM GDB folks have expressed a general
> interest in keeping the prologue analysis logic minimal and using
> Dwarf CFI everywhere.  So I'd like to outline my reasons, and see what
> the community thinks is the best approach to take.

You mean: [just for the record]: new prologue analyzer for S/390
http://sources.redhat.com/ml/gdb-patches/2003-04/msg00352.html

I thought the conclusion was that it could/should go in anyway.

As for IBM and the s390.

http://www10.software.ibm.com/developerworks/opensource/linux390/current2_4_19-may2002.shtml#debug20030416
> Note: This patch changes gdb common code in a manner that might cause problems for other platforms. Use the debugger sources created by appyling this patch only to build a debugger for the s390 or s390x architectures.

Yes, someone needs to get CFI working, but that isn't the way to do it :-(

Andrew

Re: IBM S/390 prologue analysis revisited

[Andrew Cagney]

> You mean: [just for the record]: new prologue analyzer for S/390
> http://sources.redhat.com/ml/gdb-patches/2003-04/msg00352.html

One PS,

Since this was posted (but you'd declined to commit) I added 
trad-frame.[hc].  This provides functionality that overlaps what is 
found in the s390 patch (it's slightly more compact).

> /* A traditional saved regs table, indexed by REGNUM, encoding where
>    the value of REGNUM for the previous frame can be found in this
>    frame.
> 
>    The table is initialized with an identity encoding (ADDR == -1,
>    REALREG == REGNUM) indicating that the value of REGNUM in the
>    previous frame can be found in register REGNUM (== REALREG) in this
>    frame.
> 
>    The initial encoding can then be changed:
> 
>    Modify ADDR (REALREG >= 0, ADDR != -1) to indicate that the value
>    of register REGNUM in the previous frame can be found in memory at
>    ADDR in this frame (addr_p, !realreg_p, !value_p).
> 
>    Modify REALREG (REALREG >= 0, ADDR == -1) to indicate that the
>    value of register REGNUM in the previous frame is found in register
>    REALREG in this frame (!addr_p, realreg_p, !value_p).
> 
>    Call trad_frame_register_value (REALREG == -1) to indicate that the
>    value of register REGNUM in the previous frame is found in ADDR
>    (!addr_p, !realreg_p, value_p).  */

Editor note: It's missing the undefined state.  I'll add it.

> struct trad_frame_saved_reg
> {
>   LONGEST addr; /* A CORE_ADDR fits in a longest.  */
>   int realreg;
> };
> 

Vs:

> ! struct prologue_value {
> ! 
> !   /* What sort of value is this?  This determines the interpretation
> !      of subsequent fields.  */
> !   enum {
> ! 
> !     /* We don't know anything about the value.  This is also used for
> !        values we could have kept track of, when doing so would have
> !        been too complex and we don't want to bother.  The bottom of
> !        our lattice.  */
> !     pv_unknown,
> ! 
> !     /* A known constant.  K is its value.  */
> !     pv_constant,
> ! 
> !     /* The value that register REG originally had *UPON ENTRY TO THE
> !        FUNCTION*, plus K.  If K is zero, this means, obviously, just
> !        the value REG had upon entry to the function.  REG is a GDB
> !        register number.  Before we start interpreting, we initialize
> !        every register R to { pv_register, R, 0 }.  */
> !     pv_register,
> ! 
> !   } kind;
> ! 
> !   /* The meanings of the following fields depend on 'kind'; see the
> !      comments for the specific 'kind' values.  */
> !   int reg;
> !   CORE_ADDR k;
> ! };

Given I'm, in the background, converting the old unwinders to the 
trad-frame framework (I've an i386 patch in my sandbox), it would 
probably be a good idea to merge the two.

(note that I need to commit the above revised version to trunk and branch)

enjoy,
Andrew

Re: IBM S/390 prologue analysis revisited

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:

> > You mean: [just for the record]: new prologue analyzer for S/390
> > http://sources.redhat.com/ml/gdb-patches/2003-04/msg00352.html
> 
> One PS,
> 
> Since this was posted (but you'd declined to commit) I added
> trad-frame.[hc].  This provides functionality that overlaps what is
> found in the s390 patch (it's slightly more compact).
> 
> > /* A traditional saved regs table, indexed by REGNUM, encoding where
> >    the value of REGNUM for the previous frame can be found in this
> >    frame.
> >    The table is initialized with an identity encoding (ADDR == -1,
> >    REALREG == REGNUM) indicating that the value of REGNUM in the
> >    previous frame can be found in register REGNUM (== REALREG) in this
> >    frame.
> >    The initial encoding can then be changed:
> >    Modify ADDR (REALREG >= 0, ADDR != -1) to indicate that the value
> >    of register REGNUM in the previous frame can be found in memory at
> >    ADDR in this frame (addr_p, !realreg_p, !value_p).
> >    Modify REALREG (REALREG >= 0, ADDR == -1) to indicate that the
> >    value of register REGNUM in the previous frame is found in register
> >    REALREG in this frame (!addr_p, realreg_p, !value_p).
> >    Call trad_frame_register_value (REALREG == -1) to indicate that
> > the
> >    value of register REGNUM in the previous frame is found in ADDR
> >    (!addr_p, !realreg_p, value_p).  */
> 
> Editor note: It's missing the undefined state.  I'll add it.

I'd say that 'struct trad_frame_saved_reg' and 'struct prologue_value'
are inverses of each other.  They represent information at different
steps in the process:
- First you interpret your prologue to get a bunch of prologue values.
- Then you use those to compute a set of trad_frame_saved_reg values.
- Finally, those are what you'd use to find registers.

Let me explain what I mean.

The S/390 prologue analyzer creates a table of registers' current
values, expressed as simple expressions:
  - "unknown",
  - "the constant K", or
  - "the original value of register R plus the constant K"

To build this info, you just "interpret" the prologue, starting at the
entry point, using prologue values instead of actual integers.  Here's
the code for the S/390 "add register" instruction when it appears in a
prologue:

      ...
      /* AR r1, r2 -- add register */
      else if (is_rr (insn, op_ar, &r1, &r2))
        pv_add (&gpr[r1], &gpr[r1], &gpr[r2]);
      ...

That is, you just "add" the current values of r1 and r2, and store the
"result" in r1.  (The "pv_*" functions do addition, subtraction,
etc. on prologue values, returning "unknown" whenever the answer can't
be expressed in one of the forms above.)  When you stop, you've got
the information you need to unwind: a description of the machine's
resultant state after running the prologue.

So, suppose your prologue moves the SP into the FP, and then subtracts
100 from the SP.  In that case, the S/390 prologue analyzer will end
up with the following "values" in those registers:

  SP: "the original value of SP plus the constant -100"
  FP: "the original value of SP plus the constant 0"

Given this it's easy to find the original SP, the frame size, and so
on.

But here's what's cool: suppose your prologue is actually:
- save the SP in the FP
- move the constant "-100" into register R4
- subtract R4 from SP

That extra step, going through register R4, would break a traditional
prologue analyzer, even though it's equivalent to the original
sequence (as far as SP and FP are concerned), unless you add special
code to recognize that maneuver.  But the S/390 prologue analyzer
handles this just fine, with no special cases, producing a final state
of:

  R4: "the constant -100"
  SP: "the original value of SP plus the constant -100"
  FP: "the original value of SP plus the constant 0"

So you still get the information you wanted.

This is the point where trad_frame_saved_reg comes in: that final
state information there is not exactly what you need for register
unwinding.  To find the original SP, say, you need to search the
register set for a register whose current value is "the original value
of SP plus the constant Q".  In the above case, we could recover the
original SP from either the current SP or the current FP.  (The FP is
a little easier, but if you make sure you can handle either case, then
you've got support for FP-less functions, too.)  But if you simply
make a pass over the entire register set, and record where one can
find the original values of registers, then you've produced a complete
set of 'struct trad_frame_saved_reg' values in one pass.

So as things stand, prologue values and trad_frame_saved_reg
structures are inverses of each other: they play different roles.  A
trad_frame_saved_reg points to one of the values your prologue
"interpreter" tracks: a register, stack slot, or whatever.

Re: IBM S/390 prologue analysis revisited

[Andrew Cagney]

>> Editor note: It's missing the undefined state.  I'll add it.
> 
> 
> I'd say that 'struct trad_frame_saved_reg' and 'struct prologue_value'
> are inverses of each other.  They represent information at different
> steps in the process:
> - First you interpret your prologue to get a bunch of prologue values.
> - Then you use those to compute a set of trad_frame_saved_reg values.
> - Finally, those are what you'd use to find registers.
> 
> Let me explain what I mean.

Ah!  Yes, in that case my suggestion doesn't make sense.

Can I encourage you to add this to either the s390 to trad-frame code? 
Trad frame might be better as it then provides a pointer towards the 
``new technique'' (but which ever).

Andrew


> The S/390 prologue analyzer creates a table of registers' current
> values, expressed as simple expressions:
>   - "unknown",
>   - "the constant K", or
>   - "the original value of register R plus the constant K"
> 
> To build this info, you just "interpret" the prologue, starting at the
> entry point, using prologue values instead of actual integers.  Here's
> the code for the S/390 "add register" instruction when it appears in a
> prologue:
> 
>       ...
>       /* AR r1, r2 -- add register */
>       else if (is_rr (insn, op_ar, &r1, &r2))
>         pv_add (&gpr[r1], &gpr[r1], &gpr[r2]);
>       ...
> 
> That is, you just "add" the current values of r1 and r2, and store the
> "result" in r1.  (The "pv_*" functions do addition, subtraction,
> etc. on prologue values, returning "unknown" whenever the answer can't
> be expressed in one of the forms above.)  When you stop, you've got
> the information you need to unwind: a description of the machine's
> resultant state after running the prologue.
> 
> So, suppose your prologue moves the SP into the FP, and then subtracts
> 100 from the SP.  In that case, the S/390 prologue analyzer will end
> up with the following "values" in those registers:
> 
>   SP: "the original value of SP plus the constant -100"
>   FP: "the original value of SP plus the constant 0"
> 
> Given this it's easy to find the original SP, the frame size, and so
> on.
> 
> But here's what's cool: suppose your prologue is actually:
> - save the SP in the FP
> - move the constant "-100" into register R4
> - subtract R4 from SP
> 
> That extra step, going through register R4, would break a traditional
> prologue analyzer, even though it's equivalent to the original
> sequence (as far as SP and FP are concerned), unless you add special
> code to recognize that maneuver.  But the S/390 prologue analyzer
> handles this just fine, with no special cases, producing a final state
> of:
> 
>   R4: "the constant -100"
>   SP: "the original value of SP plus the constant -100"
>   FP: "the original value of SP plus the constant 0"
> 
> So you still get the information you wanted.
> 
> This is the point where trad_frame_saved_reg comes in: that final
> state information there is not exactly what you need for register
> unwinding.  To find the original SP, say, you need to search the
> register set for a register whose current value is "the original value
> of SP plus the constant Q".  In the above case, we could recover the
> original SP from either the current SP or the current FP.  (The FP is
> a little easier, but if you make sure you can handle either case, then
> you've got support for FP-less functions, too.)  But if you simply
> make a pass over the entire register set, and record where one can
> find the original values of registers, then you've produced a complete
> set of 'struct trad_frame_saved_reg' values in one pass.
> 
> So as things stand, prologue values and trad_frame_saved_reg
> structures are inverses of each other: they play different roles.  A
> trad_frame_saved_reg points to one of the values your prologue
> "interpreter" tracks: a register, stack slot, or whatever.
> 

Re: IBM S/390 prologue analysis revisited

[Daniel Jacobowitz]

On Wed, Jul 02, 2003 at 02:33:12PM -0400, Andrew Cagney wrote:
> 
> >>Editor note: It's missing the undefined state.  I'll add it.
> >
> >
> >I'd say that 'struct trad_frame_saved_reg' and 'struct prologue_value'
> >are inverses of each other.  They represent information at different
> >steps in the process:
> >- First you interpret your prologue to get a bunch of prologue values.
> >- Then you use those to compute a set of trad_frame_saved_reg values.
> >- Finally, those are what you'd use to find registers.
> >
> >Let me explain what I mean.
> 
> Ah!  Yes, in that case my suggestion doesn't make sense.
> 
> Can I encourage you to add this to either the s390 to trad-frame code? 
> Trad frame might be better as it then provides a pointer towards the 
> ``new technique'' (but which ever).

Yeah, I'd like to see the new code outside of s390-tdep.c also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: IBM S/390 prologue analysis revisited

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> You mean: [just for the record]: new prologue analyzer for S/390
> http://sources.redhat.com/ml/gdb-patches/2003-04/msg00352.html

Yes, that's it.

> I thought the conclusion was that it could/should go in anyway.

I had been hoping folks from IBM would say something... :(