fix vsyscall unwind information
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Richard Henderson
Richard> Also adds unwind info for the sigreturn entry points. This Richard> can be used instead of special-case hacks currently in Richard> libgcc and gdb, and by extension allows the kernel to Richard> change these entry points without breaking userland.
Is there a marker or some other way to identify the sigreturn as such? If not, could one be added?
--david
Quoted 1 line · David Mosberger-Tang
Is there a marker or some other way to identify the sigreturn as such?
No.
Quoted 1 line
If not, could one be added?
Why? Certainly it isn't needed for x86.
r~
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line · Richard Henderson
If not, could one be added?
Richard> Why? Certainly it isn't needed for x86.
Certain applications (such as debuggers) want to know. Sure, you can do symbol matching (if you have the symbol table) or code-reading (assuming you know the exact sigreturn sequence), but having a marker would be more reliable and faster.
--david
Quoted 6 lines · David Mosberger-Tang
Richard> Why? Certainly it isn't needed for x86.
Certain applications (such as debuggers) want to know. Sure, you can do symbol matching (if you have the symbol table) or code-reading (assuming you know the exact sigreturn sequence), but having a marker would be more reliable and faster.
Eh. The whole point was to *eliminate* the special cases.
If the debugger does nothing special now, it'll see the symbol from the VDSO in the backtrace and print __kernel_sigreturn. Isn't this sufficient for the user to recognize what's going on? Does it really need to print <signal frame>?
r~
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Richard Henderson
Richard> On Mon, May 05, 2003 at 08:05:58AM -0700, David Richard> Mosberger-Tang wrote: Why? Certainly it isn't needed for Richard> x86.
Quoted 4 lines
Quoted 4 lines
Certain applications (such as debuggers) want to know. Sure,
you can do symbol matching (if you have the symbol table) or code-reading (assuming you know the exact sigreturn sequence), but having a marker would be more reliable and faster.
Richard> Eh. The whole point was to *eliminate* the special cases.
Signal handlers have special significance on UNIX-like operating systems. An application might want to know when it's in a signal frame. If it's a problem to do this with DWARF2 info, fine. If not, please consider adding a marker (my current version of libunwind for x86 does code-reading to detect signal-frames; not pretty, but it works reasonable well in practice; it would be nicer to get rid of the code-reading though, in the future).
--david
Quoted 8 lines · Richard Henderson
Quoted 6 lines · David Mosberger-Tang
Richard> Why? Certainly it isn't needed for x86.
Certain applications (such as debuggers) want to know. Sure, you can do symbol matching (if you have the symbol table) or code-reading (assuming you know the exact sigreturn sequence), but having a marker would be more reliable and faster.
Quoted 6 lines
Eh. The whole point was to *eliminate* the special cases.
If the debugger does nothing special now, it'll see the symbol from the VDSO in the backtrace and print
__kernel_sigreturn. Isn't this sufficient for the user to recognize what's going on? Does it really need to print <signal frame>?
Unfortunately, GDB needs to be able to recognize signal trampolines in order to be able to single step correctly when a signal arrives. At least on some platforms. Could be that the code-path in question isn't used for Linux/i386, but I vaguely remember it does.
Anyway, signal trampolines could be marked with a special augmentation in their CIE.
Mark
Quoted 2 lines · Mark Kettenis
Unfortunately, GDB needs to be able to recognize signal trampolines in order to be able to single step correctly when a signal arrives.
If it actually used the dwarf2 unwind information as written, I wouldn't expect this to be true.
Quoted 2 lines
Anyway, signal trampolines could be marked with a special augmentation in their CIE.
I'd prefer not, if at all possible.
r~
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line · Richard Henderson
Anyway, signal trampolines could be marked with a special augmentation in their CIE.
Richard> I'd prefer not, if at all possible.
Why? I bet you'll live to regret it if you don't add it now. ;-)
--david