[KLUDGE PATCH] Linux vsyscall DSO support
Andrew Cagney
cagney@gnu.org
Thu Apr 22 00:18:00 GMT 2004
>>> Last time this was discussed the observer was identified as the correct
>>> mechanim for hooking this in. That's why I'm currently overhauling that
>>> code.
>
>
> Ok. I forget many things, but I think this is news to me.
I remember sending an explicit e-mail, I suspect you didn't see it as
your mailing address got trimmed part way through the thread :-(
> I hadn't seen
> the "observer" code before; I now see it's a simple facility for running a
> list multiple hooks previously registered, so this is today's preferred
> form of adding a new hook. Two questions remain for me:
>
> What is the new hook or hooks you plan to add? i.e., will it be a single
> "look freshly at address space" hook, or separate hooks for "attached",
> "exec'd", "opened core", etc? It matters little, unless we anticipate
> future different situations that would also qualify as "look freshly at
> address space" situations but aren't one of the three I listed.
I think there should be a something like a "new_inferior" event that
incorporates "run", "attach", and "corefile". As we've recently
discovered, "run" is just a slight simplification of attach. (Because
of some screwieness in how the target vector is [isn't] designed, a
number of files will need to have the call added - that can be handled
as identified).
> Where is the right place to install our observer? My inclination is to add
> linux-tdep.c to all the Linux targets as my strawman patch does, and have
> an _initialize_linux_tdep function that registers the observers. Is that
> what you are thinking as well?
Guess so. The decsion to load one of these shlibs is really based
solely on the presence of that AT_xxxx auxv entry and the observer gets
to check that.
Andrew
More information about the Gdb-patches
mailing list