This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [just for the record]: new prologue analyzer for S/390


Andrew Cagney <ac131313 at redhat dot com> writes:
> It is important to ensure that all technical decisions related to GDB
> are discussed here, in this forum.  Issues, specific to this change,
> that come to mind, include:

I think it's okay to chat with folks off-line to get their thoughts on
a topic, as long as the decisions are made here.  I haven't sworn on a
bible not to commit the patch, just adjusted my presentation of it so
as not to shock the people who, if legal strangeness weren't in the
way, would be maintaining the code in question.

> - the unpredictability of the CFI timetable (a bird in the hand vs
> ...)

Right; I think that's the only point in favor of the patch: it does
work, and is committable right now.

> - the unpredictability of the legal processes sometimes required
> before accepting changes (must assume that the change doesn't exist)

Well, the present situation doesn't depend on any changes from IBM:
the choice is between arch-generic Dwarf 2 CFI support or mondo
prologue analysis.

> - the need to get the existing s390's frame code updated so that it
> implements frame-unwind (this is in addition, and largely orthogonal
> to the missing generic CFI unwinder).  Ignoring
> s390_get_signal_frame_info, which should be separated out, the
> attached appears to only affect the prologe analyzer so is relatively
> independant?

Yes, it's a drop-in replacement.

Even s390_get_signal_frame_info consists of code which used to be part
of the old prologue analyzer; breaking it out is a separate patch.  It
looks to me, though, that if one simply changed s390-tdep.c to use the
modern frame unwinding stuff, it would go away, or at least work very
differently, anyway.

> - the need to have gdb behave reasonably well when there is no, or
> minimal, debug info
> 
> - the need to fix the s390 problem of having a wrong frame ID
> . stack_addr (does this change address that problem?)

Nope.  Its only effect is to make prologue analysis accurate more
often.

I've put together a list of projectlets needed to bring the s390 up to
date, which I'll post in a bit; fixing the frame ID is on that list.

> - what tests it actually fixes (data?)

I'll go make that list.  It doesn't seem to have a major effect on the
test suite, but it makes a big difference when debugging optimized
code.

> > This patch assumes that IBM's s390x ABI patch has been applied.  That
> > patch is currently working its way through the IBM/FSF IP process.
> > http://sources.redhat.com/ml/gdb-patches/2003-02/msg00097.html
> 
> To be honest, I don't understand the dependency.  This patch modifies
> the prologue analysier while the other change appears to be fixing the
> push_arguments function.  While they might interact in positive ways,
> I don't think that they are dependant.

The patch doesn't apply.  The context doesn't match, textually.  There
is no major semantic dependency.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]