This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Revamp sniffer; Was: [obish?sym;rfa:doc] Wire up vsyscall
- From: Roland McGrath <roland at redhat dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Mark Kettenis <kettenis at chello dot nl>, drow at false dot org,gdb-patches at sources dot redhat dot com
- Date: Wed, 16 Jun 2004 16:07:23 -0700
- Subject: Re: Revamp sniffer; Was: [obish?sym;rfa:doc] Wire up vsyscall
I don't have all the background on gdb internals here, but I think I
understand what you've described.
On the x86, the same issue has been considered. The signal trampoline code
provided by the kernel in the vsyscall DSO (which is what gets used with
current glibc on kernels supporting it) has CFI that starts one byte before
the actual trampoline code. This comment is from the
arch/i386/kernel/vsyscall-sigreturn.S, which supplies the handwritten CFI
data in Linux 2.6 kernels:
/* HACK: The dwarf2 unwind routines will subtract 1 from the
return address to get an address in the middle of the
presumed call instruction. Since we didn't get here via
a call, we need to include the nop before the real start
to make up for it. */
In the x86-64 case, there is no kernel-supplied trampoline and current
glibc supplies one and gives it CFI. OTOH, on the x86 on kernels that do
not supply the vsyscall DSO, glibc supplies the trampoline and it provides
no CFI for it, so whatever traditional name-matching or disassembly magic
gdb does takes place instead.
If I understood your description correctly, the source of the current
problem scenario is that glibc supplies CFI for the trampoline code
(__restore_rt), but that CFI is not written to match how the peculiar frame
will look. So, glibc could change its CFI to use the same hack that the
x86 kernel CFI uses for the analogous code, or it could omit that CFI
entirely and expect gdb to recognize the name and/or instruction sequence.
My inclination is to omit the CFI because that's how it is on x86 in the
analogous case. (If in future x86-64 has kernel-supplied trampoline code,
we expect it will be in the form of a vsyscall DSO that supplies CFI via
existing glibc support, as on x86. In that case, the CFI will use the same
sort of hack as the x86 CFI does.) Would that make things better?
Thanks,
Roland