This is the mail archive of the gdb-patches@sourceware.org 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: RFA: general prologue analysis framework


Daniel Jacobowitz <drow@false.org> writes:
> I'd love to see the m32c example.  The arithmetic is easy to grasp, but
> the choices you made for memory (and the special-case for array
> references) are a lot less obvious without some more context.

I've attached the current m32c-tdep.c.

pv_is_array_ref is strictly a utility function; there's nothing in
there you couldn't do with the existing primitives.  It was used in
the original s390 analyzer, but nothing uses it now.  S390 frames have
(had?) distinct areas set up for saving gprs and fprs, and they're
always full-sized.  I used pv_is_array_ref to recognize stores to
those areas.  The 'pv_area' functions are new; I think they'd handle
the problem better.

> I have a half-baked feeling that the exported interface is at a bad
> level of abstraction, i.e. that too much generic code will end up
> crammed into the tdep files.  But I don't have any evidence to back
> that up.

Let me know what you think after seeing m32c-tdep.c.  And if we ever
get to contribute the other port (the customer is fine with that, but
it's on an old branch, so it would have to be forward-ported, and the
customer isn't eager to pay for that), you could see what the two have
in common.

Both my interpreters have some common code to recognize frame-building
instructions, to distinguish fixed-size from variable-sized frames,
and to locate saved registers.  I can imagine that stuff being lifted
out, but it seems like the kind of thing that's prone to
processor-specific tweaks.  The last thing we need is another hairy
function that's used by a zillion ports so we can't change its
behavior.

But I'd be happy to see a clean alternative.

> This all screams out to me that we ought to be able to generate most of
> the target-specific bits from cgen or somehow reuse existing simulator
> interfaces.  Now that'd be extra credit.

*Exactly*.  Machine-independent prologue analysis!  If we had a
machine description in CSDL or something like that, writing the
prologue analyzer would probably require little more than indicating
which instructions you wanted to recognize.

Attachment: m32c-tdep.c
Description: M32C target-dependent GDB code


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