Re: [KLUDGE PATCH] Linux vsyscall DSO support

[Andrew Cagney <cagney@gnu.org>]

>>> 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