Re: Linux kernel problem -- food for thoughts

[Roland McGrath <roland@redhat.com>]

> I was just thinking about this.  My reaction is:
>   - the page needs to be readable; I vaguely remember badgering Linus
> about this and getting it fixed, but it might have been someone else,
> or it might not have gotten fixed.

Or maybe you just got (or replicated) the half-assed patch I did for this,
which only went to Linus yesterday.

>   - GDB needs to get the location of the EH information from glibc
> somehow.  My instinct is to make glibc export this in a global symbol,
> just like the way we get signal numbers from linuxthreads.

Bletch.  libc isn't the source of the information.  You could have a
program that doesn't use glibc and since winds up at these PC locations.
gdb should get the information from the kernel directly somehow.

[Elena:]
> Roland (but I'll let him speak) has had a thought about creating a
> /proc/pid/vsyscall file, which then gdb could read with add-symbol-file....

I implemented this as a quick hack.  I can send the 2.5 kernel patch to
anyone who is interested.  I am pretty sure this wouldn't get integrated
into the kernel if I lobbied for it.  Since the same address is used in
every process (at least in all the kernels around now), it's also easy to
use a little program (which I wrote first) to generate the file from the
running kernel and then you can use that plain file with add-symbol-file.

This is what I recommend we use for the first development step.  That is,
when the DWARF unwinding support for x86 is enabled generically, we can try
the add-symbol-file trick (or an internal call kludged in) for the purposes
of testing and debugging the unwinding, seeing the testsuite run happily
with good backtraces, etc.  It seems unlikely to be a good real implementation.

For core files, I do think the only sensible thing will be to make the
kernel write the vsyscall page into every core dump.  Otherwise you can't
always be sure when looking at a post-mortem exactly what the PC values it
was using while alive meant at the time.  

For a live implementation not relying on a virtual ELF file, and for core
files, there remains the issue of finding the .eh_frame start address.  I
have some thoughts, and that's a relatively minor detail to be worked out
once the whole plan of using that info is agreed upon.


Thanks,
Roland