Re: [branch patch] core files as symfiles

[Roland McGrath <roland at redhat dot com>]

> Did we settle on this being the solution though? I think the
> /proc/PID/auxv approach is a bit cleaner. 

We're talking about core files, so what you mean is an NT_AUXV note that
would give the same information that /proc/PID/auxv would give for a live
process.  It remains to see whether the auxv approach will be accepted in
the kernel.  

If that is done, then the corelow.c patch will be superfluous.  I would
like feedback on the implementation issue of this patch regardless.  That
is, if anyone sees any potential problems with adding the core bfd as a
symfile (AFAIK it's a no-op to all cases but the new vsyscall issues), or
with my specific code changes.  Then I can address any nits, and verify
that it is a safe change for gdb generically speaking.  It is useful to
know ASAP that this very simple change works acceptably, even if it turns
out not to be necessary in the end.

Using the core file's phdrs (which is what happens implicitly using this
patch) has the benefit that it works now, i.e. with kernel support already
merged into Linux 2.5, and with gdb code I have already finished enough to
be in submittable form.  If the generic auxv exporting support is not
accepted in the kernel, then it is quite likely that some other way to know
the vsyscall DSO address in a live process (e.g. via /proc/PID/maps) *will*
be accepted, but no other core dump changes will go in and the existing
phdrs will be the only method for the core dump case.


Thanks,
Roland