Re: gdb support for Linux vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

> No work has yet been done to convert GDB's ia64 target to make it use
> the new frame unwinder framework.  Andrew's idea was that it should be
> possible to just hook the frame unwind methods into an existing
> target, but that hasn't been tested yet.

Ok.  I am not going to worry about IA64 work per se for now.  I mentioned
it because the DSO issues are the same as the x86 case and so most of the
work I've suggested can be machine-independent.

> The run-time dynamic linker's data structures usually are intact, but
> a fall-back mechanism wouldn't hurt I guess.

The stack is usually intact too. ;-) It would not be the end of the world
to rely on the dynamic linker's data structures.  In practice, they are
intact and people don't use the vsyscall entrypoint in statically linked
programs.  But I would rather consider *that* the fallback to be used in
remote situations where the kernel inquiry mechanism isn't available.  If
there is a kernel inquiry mechanism, it will always be correct.  If there
are dynamic linker data structures at all, they might be bogus so you don't
want to use them preferentially.

> OK, as long as we try to keep the code as generic as possible and
> isolate platform-specific hacks in platform-specific files.

You know me.

> Note that symbols from the vsyscall would be very helpful to the user.

Surely.  But lack thereof doesn't cripple the user the way failure to
unwind the frame does, so it's not the highest priority.  That's all I said.

> There is also an issue with signal trampolines.  GDB needs to be able
> to recognize them in order to support stepping over functions when a
> signal arrives.  

I don't think I know exactly what you mean here.  Is there a special case
for signal frames aside from just knowing how to unwind them properly?
(The only other specialness I am aware of is "<signal handler called>",
which with normal unwind info would show __kernel_sigreturn instead.)

> I proposed Richard Henderson to add a special DWARF CFI augmentation to
> mark __kernel_sigreturn and __kernel_rt_sigreturn as signal trampolines.
> That would allow me to recognize them without knowing their names.

The code I have seen looks at the instruction sequence to match the
expected system call (using "int $0x80").  All extant Linux kernels still
have those same exact instruction sequences (as libc's __restore and
__restore_rt).  So this will continue to work, ugly as it is.  Not that we
shouldn't address it more cleanly, but I don't think it's in fact breaking
anything at this very moment.

rth has added unwind info to the __kernel_{rt_,}sigreturn vsyscall code.
These describe unwinding the signal frame to restore all the registers to
the state that was interrupted by the signal (though not the processor
flags word, I dunno if i386 DWARF2 format can do that--you'd only need that
if you wanted to roll back the signal handling frame as if it had never
happened at all, not just to unwind past it or examine the frame's state).  

> Ordinary shared libraries are cleared out in core_close() by
> CLEAR_SOLIB().  This calls solib.c:clear_solib(), so I think you
> should remove things in that codepath.

Ok.

> Relying on the dynamic linker's data structures certainly seems
> attractive to me as an additional method since it works independently
> of the remote protocol.

Agreed.  I was vaguely hoping that someone would have a brilliant idea
that is both remote-friendly and as robust as the kernel-specific
backend solutions, but I don't think there is one possible.

> To avoid kludging around one could:

These are the obvious suggestions.  I am very hesitant to change the
exposed structures; frankly, those two will probably never change again.
The dynamic tag would be a convenient one, but would require an ld change
and to be sure your kernel was built by a new enough ld; that is impractical.

Exposing some way to get the l_phdr pointer is very reasonable.  An idea
that doesn't raise many of the issues of changing the public `struct link_map'
layout is export an internal symbol giving offsetof (struct link_map, l_phdr).
That is still sort of a kludge if you ask me.  But it shouldn't cause many
problems in practice.

>    to make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way
> 
> That would probably be better that reading /proc/PID/auxv out of the
> process stack.

Agreed.