Re: [PATCH] JIT read_debug_info callback takes target symfile addr

[Andy Wingo <wingo@igalia.com>]

Hi Doug,

On Wed 25 Feb 2015 19:17, Doug Evans <xdje42@gmail.com> writes:

> Hi. A couple of high level comments.
>
> 1) My understanding is that we still need to support older versions of
> the interface, at least for awhile.
> Our currently deprecation policy is to never break anything
> (or something within epsilon of that).

Cool.  It's not a particular problem to support an older interface.

> This doesn't scale. I'd like to see a formal policy where things
> can live in a deprecated state for pre-specified awhile, after which
> they can be deleted.

ACK.

> 2) It's not clear to me whether we want to continue extending the JIT
> interface, or just move it to the extension languages.
> We'd still keep the existing interface, deprecated.
> I'm not proposing we actually do this, at least not today.

Yeah, I know what you mean.  After having some experience with this
(https://groups.google.com/forum/#!topic/v8-users/y18bmM2I5L0) I don't
think the JIT interface is really the right thing for the future.

For C JIT reader extensions, you really don't have enough of an
interface to do many interesting things.

For extension languages, it doesn't feel quite right; you can use
make-value and value-cast and all those things to turn the spare
interface of the custom JIT debuginfo reader into something that feels
more like the normal extension language, but you still lack a lot of
information from the inferior.  For example, the architecture seems to
be a property of the frame, but you can't get at the current frame
object from the extension.  Likewise specifying registers by DWARF ID is
not so nice.  It would be nice if the read-register interface would
return values of the proper size, as proper GDB values -- in my patch I
am returning them as bytevectors because hey, registers are different
sizes, but then you still don't have information on how they should be
interpreted.  But that's not something you want to force an extension
writer to know about.

The JIT interface also seems to encourage native (not cross)
development, because you have little information about the target.

Finally the JIT reader callbacks are awkward.  I wish actually that I
could unwind frames from the target without requiring the target to
integrate with GDB in any way.  I could do that from Guile for V8, for
example, at least for the V8 part of the stack (see mail I linked
above).  What I would really like would be a callback to ask the
Guile/Python extension "is this a frame you know about?" and then if so,
let the extension unwind it.  Then I wouldn't have to modify the target
in any way, which would be a relief.

What is the right mailing list to discuss these things?  Who are the
right people?  I'm happy to do work off and on around these things, if
you are interested.

Andy