gdb/dwarf-frame.c

gdb/dwarf-frame.c

[Roland McGrath]

(Hi Mark!  It's been too long since we hacked together.)
[Please note that I am not on the mailing list, so keep me CC'd directly.]

I have been looking at the kettenis_i386newframe-20030419-branch gdb code.
I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code
that's on mainline.  I don't know the guts of either or of DWARF2 itself
well enough to compare them.

What I have noticed is that dwarf-frame.c does not seem to handle the
.eh_frame section, only the .debug_frame section.  The dwarf2cfi.c code
looks at both.  As well as looking for the section, it needs to grok the
"augmentation" values and different encodings used in .eh_frame, and I
don't see any of that handled in the new code.  Is this an intentional
omission and if so what is the rationale?

I think grokking .eh_frame sections in the absence of .debug_frame is a
nice thing in general--it might give you at least some more helpful
backtraces than otherwise when dealing with binaries without debugging
info.  But the particular reason it is of concern to me is that it's needed
for unwinding PC values within the special kernel entrypoint page now being
used in Linux on x86.  glibc now uses this entrypoint code for every system
call, and so any thread blocked in a system call (which most threads one
looks at are when one starts looking) will have its PC inside this code and
need to be able to unwind that frame-pointer-less leaf frame to produce a
useful backtrace.  This is magic kernel code for which there is never going
to be debugging information, but for which we do have .eh_frame information
we can get at.  I am setting about attacking how we get at it in all the
relevant cases, but I had been working from the assumption that upon
locating some information in .eh_frame form (including "zR" augmentation
and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding
machinery.  If that's not so, it throws a monkey wrench into my plans.


Thanks,
Roland

Re: gdb/dwarf-frame.c

[Daniel Jacobowitz]

On Fri, May 09, 2003 at 02:45:29AM -0700, Roland McGrath wrote:
> (Hi Mark!  It's been too long since we hacked together.)
> [Please note that I am not on the mailing list, so keep me CC'd directly.]
> 
> I have been looking at the kettenis_i386newframe-20030419-branch gdb code.
> I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code
> that's on mainline.  I don't know the guts of either or of DWARF2 itself
> well enough to compare them.
> 
> What I have noticed is that dwarf-frame.c does not seem to handle the
> .eh_frame section, only the .debug_frame section.  The dwarf2cfi.c code
> looks at both.  As well as looking for the section, it needs to grok the
> "augmentation" values and different encodings used in .eh_frame, and I
> don't see any of that handled in the new code.  Is this an intentional
> omission and if so what is the rationale?

My understanding from Mark's earlier post is that it is an intentional
but probably temporary omission - since dwarf-frame is only a week or
two old at this point.

> I think grokking .eh_frame sections in the absence of .debug_frame is a
> nice thing in general--it might give you at least some more helpful
> backtraces than otherwise when dealing with binaries without debugging
> info.  But the particular reason it is of concern to me is that it's needed
> for unwinding PC values within the special kernel entrypoint page now being
> used in Linux on x86.  glibc now uses this entrypoint code for every system
> call, and so any thread blocked in a system call (which most threads one
> looks at are when one starts looking) will have its PC inside this code and
> need to be able to unwind that frame-pointer-less leaf frame to produce a
> useful backtrace.  This is magic kernel code for which there is never going
> to be debugging information, but for which we do have .eh_frame information
> we can get at.  I am setting about attacking how we get at it in all the
> relevant cases, but I had been working from the assumption that upon
> locating some information in .eh_frame form (including "zR" augmentation
> and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding
> machinery.  If that's not so, it throws a monkey wrench into my plans.

Should any work even be necessary?  My understanding was that the
kernel code would show up in the shared library list.  Oh, I guess it
is - we usually locate .eh_frame via BFD, which means section headers
and an on-disk file.  I see.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb/dwarf-frame.c

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Fri, May 09, 2003 at 02:45:29AM -0700, Roland McGrath wrote:
 > > (Hi Mark!  It's been too long since we hacked together.)
 > > [Please note that I am not on the mailing list, so keep me CC'd directly.]
 > > 
 > > I have been looking at the kettenis_i386newframe-20030419-branch gdb code.
 > > I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code
 > > that's on mainline.  I don't know the guts of either or of DWARF2 itself
 > > well enough to compare them.
 > > 
 > > What I have noticed is that dwarf-frame.c does not seem to handle the
 > > .eh_frame section, only the .debug_frame section.  The dwarf2cfi.c code
 > > looks at both.  As well as looking for the section, it needs to grok the
 > > "augmentation" values and different encodings used in .eh_frame, and I
 > > don't see any of that handled in the new code.  Is this an intentional
 > > omission and if so what is the rationale?
 > 
 > My understanding from Mark's earlier post is that it is an intentional
 > but probably temporary omission - since dwarf-frame is only a week or
 > two old at this point.
 > 
 > > I think grokking .eh_frame sections in the absence of .debug_frame is a
 > > nice thing in general--it might give you at least some more helpful
 > > backtraces than otherwise when dealing with binaries without debugging
 > > info.  But the particular reason it is of concern to me is that it's needed
 > > for unwinding PC values within the special kernel entrypoint page now being
 > > used in Linux on x86.  glibc now uses this entrypoint code for every system
 > > call, and so any thread blocked in a system call (which most threads one
 > > looks at are when one starts looking) will have its PC inside this code and
 > > need to be able to unwind that frame-pointer-less leaf frame to produce a
 > > useful backtrace.  This is magic kernel code for which there is never going
 > > to be debugging information, but for which we do have .eh_frame information
 > > we can get at.  I am setting about attacking how we get at it in all the
 > > relevant cases, but I had been working from the assumption that upon
 > > locating some information in .eh_frame form (including "zR" augmentation
 > > and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding
 > > machinery.  If that's not so, it throws a monkey wrench into my plans.
 > 
 > Should any work even be necessary?  My understanding was that the
 > kernel code would show up in the shared library list.  Oh, I guess it
 > is - we usually locate .eh_frame via BFD, which means section headers
 > and an on-disk file.  I see.
 > 

Which reminds me that we should probably have the NPTL thread support
patches integrated in gdb as well, since we are at this (and I have
your attention). Can somebody (Daniel, Mark?) take a look at the
patches? I can guarentee that they work, since they were shipped with
RHL9's gdb.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

NPTL thread support

[H. J. Lu]

On Fri, May 09, 2003 at 10:15:05AM -0400, Elena Zannoni wrote:
> 
> Which reminds me that we should probably have the NPTL thread support
> patches integrated in gdb as well, since we are at this (and I have
> your attention). Can somebody (Daniel, Mark?) take a look at the
> patches? I can guarentee that they work, since they were shipped with
> RHL9's gdb.
> 

Yes, please. I have to use gdb from cvs since the one RedHat 9 doesn't
work too well for me. But I lose the NPTL support.


H.J.

Re: NPTL thread support

[Elena Zannoni]

H. J. Lu writes:
 > On Fri, May 09, 2003 at 10:15:05AM -0400, Elena Zannoni wrote:
 > > 
 > > Which reminds me that we should probably have the NPTL thread support
 > > patches integrated in gdb as well, since we are at this (and I have
 > > your attention). Can somebody (Daniel, Mark?) take a look at the
 > > patches? I can guarentee that they work, since they were shipped with
 > > RHL9's gdb.
 > > 
 > 
 > Yes, please. I have to use gdb from cvs since the one RedHat 9 doesn't
 > work too well for me. But I lose the NPTL support.
 > 
 > 
 > H.J.

yes, catch 22. RHL9's gdb is based from a snapshot of November 2002,
it doesn't have a lot of the new fixes.

elena

Re: gdb/dwarf-frame.c

[Andrew Cagney]

> Which reminds me that we should probably have the NPTL thread support
> patches integrated in gdb as well, since we are at this (and I have
> your attention). Can somebody (Daniel, Mark?) take a look at the
> patches? I can guarentee that they work, since they were shipped with
> RHL9's gdb.

Just FYI, Michael or Mark.  I don't think Mark is exactly comfortable 
with the Linux thread stuff so ...

Michael?

Daniel's ``thumbs up'' would be very helpful though.

Andrew

Re: gdb/dwarf-frame.c

[Elena Zannoni]

Andrew Cagney writes:
 > 
 > > Which reminds me that we should probably have the NPTL thread support
 > > patches integrated in gdb as well, since we are at this (and I have
 > > your attention). Can somebody (Daniel, Mark?) take a look at the
 > > patches? I can guarentee that they work, since they were shipped with
 > > RHL9's gdb.
 > 
 > Just FYI, Michael or Mark.  I don't think Mark is exactly comfortable 
 > with the Linux thread stuff so ...
 > 
 > Michael?
 > 
 > Daniel's ``thumbs up'' would be very helpful though.
 > 


And HJ's.

elena


 > Andrew
 > 

Re: gdb/dwarf-frame.c

[Mark Kettenis]

   Date: Fri, 9 May 2003 02:45:29 -0700
   From: Roland McGrath <roland@redhat.com>

   (Hi Mark!  It's been too long since we hacked together.)

(Hi Roland!  I've drifted away a bit from glibc and the Hurd :-(.)

   [Please note that I am not on the mailing list, so keep me CC'd directly.]

   I have been looking at the kettenis_i386newframe-20030419-branch gdb code.
   I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code
   that's on mainline.  I don't know the guts of either or of DWARF2 itself
   well enough to compare them.

dwarf2cfi.c currently has more complete support for DWARF CFI, but
suffers from some design flaws, which probably makes it unusable for
debugging any serious project.

   What I have noticed is that dwarf-frame.c does not seem to handle the
   .eh_frame section, only the .debug_frame section.  The dwarf2cfi.c code
   looks at both.  As well as looking for the section, it needs to grok the
   "augmentation" values and different encodings used in .eh_frame, and I
   don't see any of that handled in the new code.  Is this an intentional
   omission and if so what is the rationale?

Daniel is right here.  I'm busy writting the support for .eh_frame
sections.  I just left them out since they complicate matters quite a
bit.

   I think grokking .eh_frame sections in the absence of .debug_frame is a
   nice thing in general--it might give you at least some more helpful
   backtraces than otherwise when dealing with binaries without debugging
   info.  But the particular reason it is of concern to me is that it's needed
   for unwinding PC values within the special kernel entrypoint page now being
   used in Linux on x86.  glibc now uses this entrypoint code for every system
   call, and so any thread blocked in a system call (which most threads one
   looks at are when one starts looking) will have its PC inside this code and
   need to be able to unwind that frame-pointer-less leaf frame to produce a
   useful backtrace.  This is magic kernel code for which there is never going
   to be debugging information, but for which we do have .eh_frame information
   we can get at.  I am setting about attacking how we get at it in all the
   relevant cases, but I had been working from the assumption that upon
   locating some information in .eh_frame form (including "zR" augmentation
   and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding
   machinery.  If that's not so, it throws a monkey wrench into my plans.

It certainly is my intention to make it possible, although It's not
clear how things should be glued together.  I've seen your kernel
patches and it seems as if there are two possibilities:

1. Reading the complete DSO from target memory, and somehow turning it
   in a bfd.  That would make it possible to use the existing symbol
   reading machinere to read symbols and .eh_frame info.

2. Write a symbol reader that uses the run-tume dynamic linker (struct
   r_debug, struct link_map) to locate the dynamic section of the
   shared object, and uses it to read the relevant loaded sections of
   the DSO from the target and interpret those bits.

If I'm not mistaken, the latter would also allow us to construct a
minimal symbol table for DSO's even if the we don't have access to an
on-disk file.  We'll probably need some serious hacking on GDB's
shared library support to make this all possible.

Mark

Re: gdb/dwarf-frame.c

[Mark Kettenis]

   Date: Fri, 09 May 2003 13:00:54 -0400
   From: Andrew Cagney <ac131313@redhat.com>

   > Which reminds me that we should probably have the NPTL thread support
   > patches integrated in gdb as well, since we are at this (and I have
   > your attention). Can somebody (Daniel, Mark?) take a look at the
   > patches? I can guarentee that they work, since they were shipped with
   > RHL9's gdb.

   Just FYI, Michael or Mark.  I don't think Mark is exactly comfortable 
   with the Linux thread stuff so ...

Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
haven't tracked what's been happening on the Linux thread front too
closely.  I get the feeling though that trying to support both the old
and the new threading model in the same code isn't a good idea :-(.

Mark

Re: gdb/dwarf-frame.c

[Roland McGrath]

> My understanding from Mark's earlier post is that it is an intentional
> but probably temporary omission - since dwarf-frame is only a week or
> two old at this point.

I want it all and I want it now, dammit!  No, wait, wrong attitude module.
That's what I was hoping to hear.  Perhaps I can lend a hand to speed up
the process of implementing the rest of it.

> Should any work even be necessary?  My understanding was that the
> kernel code would show up in the shared library list.  Oh, I guess it
> is - we usually locate .eh_frame via BFD, which means section headers
> and an on-disk file.  I see.

Indeedy.


Thanks,
Roland

Re: gdb/dwarf-frame.c

[Roland McGrath]

[I trimmed the CC because I think everyone else is on the mailing list.]

> Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
> haven't tracked what's been happening on the Linux thread front too
> closely.  I get the feeling though that trying to support both the old
> and the new threading model in the same code isn't a good idea :-(.

Can you be specific in your criticism?  The rigamarole to get sibling
threads stopped and started is a bit unsightly, but not too horrible I
didn't think.  I think trying to have separate backend implementations for
linuxthreads and nptl and switching among them (whether two target modules
or one with internal state flags) would be worse than any moderate amount
of kludgery in the one backend.  

The situation in lin-lwp.c can be much cleaner if Dan and I ever implement
the enhancements to ptrace in Linux 2.5 that we have discussed in detail
privately in the past.  That would let thread tracing at the kernel level
work in a sane fashion with either kind of threads on a new kernel, and
make it easy to detect an old kernel lacking the new ptrace features and
fall back to the existing code that only supports linuxthreads.  We can
probably be spurred to do this, though it has heretofore fallen off the end
of our queues of wonderful things that ought to be done real soon now.

That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4
kernels that support NPTL like those in RHL9.  But personally I am ok with
such support not going into mainline gdb if cleaner support for newer
kernels is there.  (However I don't speak for my RH colleagues who will
have to maintain private patches as necessary.)


Thanks,
Roland

Re: gdb/dwarf-frame.c

[Roland McGrath]

> Daniel is right here.  I'm busy writting the support for .eh_frame
> sections.  I just left them out since they complicate matters quite a
> bit.

Great!  Anything you can tell me about your progress on that code is much
appreciated.  I would be happy to help test and debug unfinished changes.

Re: gdb/dwarf-frame.c

[Elena Zannoni]

Roland McGrath writes:
 > > Daniel is right here.  I'm busy writting the support for .eh_frame
 > > sections.  I just left them out since they complicate matters quite a
 > > bit.
 > 
 > Great!  Anything you can tell me about your progress on that code is much
 > appreciated.  I would be happy to help test and debug unfinished changes.


Going back to the original reason of the posting, Roland, do you have
some particular design in mind as to the interface to retrieve the DSO
information?

elena

Re: gdb/dwarf-frame.c

[Elena Zannoni]

Roland McGrath writes:
 > [I trimmed the CC because I think everyone else is on the mailing list.]
 > 
 > > Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
 > > haven't tracked what's been happening on the Linux thread front too
 > > closely.  I get the feeling though that trying to support both the old
 > > and the new threading model in the same code isn't a good idea :-(.
 > 
 > Can you be specific in your criticism?  The rigamarole to get sibling
 > threads stopped and started is a bit unsightly, but not too horrible I
 > didn't think.  I think trying to have separate backend implementations for
 > linuxthreads and nptl and switching among them (whether two target modules
 > or one with internal state flags) would be worse than any moderate amount
 > of kludgery in the one backend.  
 > 
 > The situation in lin-lwp.c can be much cleaner if Dan and I ever implement
 > the enhancements to ptrace in Linux 2.5 that we have discussed in detail
 > privately in the past.  That would let thread tracing at the kernel level
 > work in a sane fashion with either kind of threads on a new kernel, and
 > make it easy to detect an old kernel lacking the new ptrace features and
 > fall back to the existing code that only supports linuxthreads.  We can
 > probably be spurred to do this, though it has heretofore fallen off the end
 > of our queues of wonderful things that ought to be done real soon now.
 > 
 > That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4
 > kernels that support NPTL like those in RHL9.  But personally I am ok with
 > such support not going into mainline gdb if cleaner support for newer
 > kernels is there.  (However I don't speak for my RH colleagues who will
 > have to maintain private patches as necessary.)
 > 

<FSF hat> 

I don't think it is a good idea for gdb6 to be broken on the most
recent linux kernels.

elena

 > 
 > Thanks,
 > Roland

Re: gdb/dwarf-frame.c

[Andrew Cagney]

Roland,

You can't seriously suggest that GDB should intentionally allow itself 
to remain broken on very mainstream and released GNU/Linux systems (such 
as Red Hat 9).

Andrew

Re: gdb/dwarf-frame.c

[Daniel Jacobowitz]

On Fri, May 09, 2003 at 02:19:31PM -0700, Roland McGrath wrote:
> [I trimmed the CC because I think everyone else is on the mailing list.]
> 
> > Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
> > haven't tracked what's been happening on the Linux thread front too
> > closely.  I get the feeling though that trying to support both the old
> > and the new threading model in the same code isn't a good idea :-(.
> 
> Can you be specific in your criticism?  The rigamarole to get sibling
> threads stopped and started is a bit unsightly, but not too horrible I
> didn't think.  I think trying to have separate backend implementations for
> linuxthreads and nptl and switching among them (whether two target modules
> or one with internal state flags) would be worse than any moderate amount
> of kludgery in the one backend.  
> 
> The situation in lin-lwp.c can be much cleaner if Dan and I ever implement
> the enhancements to ptrace in Linux 2.5 that we have discussed in detail
> privately in the past.  That would let thread tracing at the kernel level
> work in a sane fashion with either kind of threads on a new kernel, and
> make it easy to detect an old kernel lacking the new ptrace features and
> fall back to the existing code that only supports linuxthreads.  We can
> probably be spurred to do this, though it has heretofore fallen off the end
> of our queues of wonderful things that ought to be done real soon now.

Coincidentally, I'm working on this this weekend.  Or I was going to. 
The NPTL gdb patches do _not_ work on 2.5.69.  The message about this
is stuck in my outbox; I'm trying to get GDB to give me a backtrace but
it's been chugging for an hour now with no luck (160K frames and
counting!)

> That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4
> kernels that support NPTL like those in RHL9.  But personally I am ok with
> such support not going into mainline gdb if cleaner support for newer
> kernels is there.  (However I don't speak for my RH colleagues who will
> have to maintain private patches as necessary.)

I'd rather support it.  I think we can, too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb/dwarf-frame.c

[Roland McGrath]

> <FSF hat> 
> 
> I don't think it is a good idea for gdb6 to be broken on the most
> recent linux kernels.

Last I knew the GNU notion was to worry about "mainstream" kernels, which
means vanilla released Linux 2.4.x and bleeding edge Linux 2.5.x (which
changes its interfaces incompatibly between x's, since it's an experimental
development version).

> Roland,
> 
> You can't seriously suggest that GDB should intentionally allow itself 
> to remain broken on very mainstream and released GNU/Linux systems (such 
> as Red Hat 9).
> 
> Andrew

Actually, I was saying that I wouldn't be arguing for code considered ugly
(and that is just my impression of how Mark's opinion was charcterized from
what I saw being said, not anything to be taken as meaning anything) to be
in mainline gdb for the support RHL-modified kernels versions.  I didn't
say I would argue against it, either.  That's up to the people who have gdb
hats not made of flash paper like mine is.

> I'd rather support it.  I think we can, too.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Well, good!  I know we can.  I and everyone else at RH would surely prefer
it if we did.  I'm glad to hear that other people want to.

Re: gdb/dwarf-frame.c

[Roland McGrath]

> Coincidentally, I'm working on this this weekend.  Or I was going to. 
> The NPTL gdb patches do _not_ work on 2.5.69.  The message about this
> is stuck in my outbox; I'm trying to get GDB to give me a backtrace but
> it's been chugging for an hour now with no luck (160K frames and
> counting!)

Ok, I can hack on this.  Post whatever details you have and I'll get started.

Re: gdb/dwarf-frame.c

[Andrew Cagney]

>    Date: Fri, 09 May 2003 13:00:54 -0400
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    > Which reminds me that we should probably have the NPTL thread support
>    > patches integrated in gdb as well, since we are at this (and I have
>    > your attention). Can somebody (Daniel, Mark?) take a look at the
>    > patches? I can guarentee that they work, since they were shipped with
>    > RHL9's gdb.
> 
>    Just FYI, Michael or Mark.  I don't think Mark is exactly comfortable 
>    with the Linux thread stuff so ...
> 
> Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
> haven't tracked what's been happening on the Linux thread front too
> closely.  I get the feeling though that trying to support both the old
> and the new threading model in the same code isn't a good idea :-(.

There is apparently a story here.  I'm told that some people were 
arguing that GDB would need a complete rewrite if it were to ever 
support NPTL.  Turned out to effectively be the oposite.

Andrew

Re: gdb/dwarf-frame.c

[Roland McGrath]

> There is apparently a story here.  I'm told that some people were 
> arguing that GDB would need a complete rewrite if it were to ever 
> support NPTL.  Turned out to effectively be the oposite.

If you mean that the Linux kernel's ptrace implementation needed to be
majorly overhauled to support its new kernel threads implementation even a
little bit sensically, tnen yes.

gdb support for Linux vsyscall DSO

[Roland McGrath]

[I changed the subject of the thread to distinguish this part of the
discussion from the state of DWARF CFI, which is a prerequisite but
independent.]

It's notable that I didn't say i386 in the subject.  I am helping David
Mosberger implement the same concept on ia64 in Linux 2.5 as well.  When
glibc starts using those entry points on Linux/ia64 (it doesn't yet), then
there will be the same issues for getting at the unwind info.  The vsyscall
DSO plan will be the same, so getting at the ELF sections is addressed the
same way (more on that below).  In the ia64 case, the unwind info is ia64's
flavor rather than DWARF2 flavor, but the use of ELF phdrs and sections to
locate it is precisely analogous.

> It certainly is my intention to make it possible, although It's not
> clear how things should be glued together.  

As you might imagine, I had thought through most of the details of what gdb
needs to do when I made the kernel changes (whose main purpose for me was
to make the gdb support possible).  There are two cases that need to be
addressed.  You've brought up the case of live processes.  There is also
the case of core dumps.

> I've seen your kernel patches and it seems as if there are two
> possibilities:

You omitted possibility #0, which I had intended to preemptively describe
and explain why I rejected it.  That is, to have some file that gdb can
read.  It would be simple to have a /proc file that gives you the DSO image
as a virtual file, and have the dynamic linker's shlib list refer to this
file name.  Then gdb might not need any change at all.  However, this sucks
rocks for remote debugging.  It also doesn't sit right with me because the
vsyscall DSO is actually there and your PC might be in it, even if you are
not using the dynamic linker or glibc at all and have no "info shared" list.

> 1. Reading the complete DSO from target memory, and somehow turning it
>    in a bfd.  That would make it possible to use the existing symbol
>    reading machinere to read symbols and .eh_frame info.

This is what I had anticipated doing, at least the first cut.  Given some
true assumptions about the vsyscall DSO, it is trivial to compute the total
file size from the ELF headers and recover the byte image of the file
exactly.  It can't be too hard to fake up a bfd in memory as if the
contents had been read from a file.

Having a bfd of the DSO file makes it simple to plug it into the existing
code that looks for the sections by name.  I do have one minor concern
about that.  An ELF stripping utility is well within its rights to remove
the section headers entirely from a DSO, and such DSOs work fine.  The
binutils and elfutils strip do not do this (nor ld -s, nor anything else
using bfd), but they could one day.  If the kernel people decide to shave
off 149 bytes from the image by getting rid of the section headers and
.shstrtab, it's hard for me to argue that they really shouldn't do that.
And any stripped ELF DSO could reasonably have its section headers removed
for whatever reason.  I think this would be addressed adequately by having
bfd do the same faking of sections based on ELF phdrs that it does for core
files, on any ELF file that has no section headers but does have phdrs.
But that is not an immediate concern, just something to air.

Let's assume we can fake a bfd containing the DSO file contents by finding
its ELF header in the inferior's memory.  Right now it would be a
digression to go into how we know where to look; I will get into that at
the end.  At this point it seems apropos to describe the core file
situation before getting to your #2.

Core files are sectionless ELF files that have ELF program headers.  In the
vsyscall DSO changes, I made Linux core dumps include the DSO image as part
of the memory dump (just as it appeared in memory) and also copy the DSO's
special phdrs to the core file, with adjusted file offsets.  Hence a new
Linux core dump has both a PT_GNU_EH_FRAME pointing at the DSO's
.eh_frame_hdr section and a PT_DYNAMIC pointing at its .dynamic section.
In these phdrs, p_vaddr and other fields match those phdrs in the DSO, but
p_offset gives the position in the core dump file where that section within
the DSO file image appears.  This means that the existing section-faking
code for ELF core files (including my recent change to it) will give a core
file bfd sections called "eh_frame_hdr13" and "dynamic12" or suchlike.

I made simple changes to dwarf2read.c to match sections named
"eh_frame_hdr*" as it matches ".eh_frame", and to dwarf2cfi.c to grok the
.eh_frame_hdr format to locate .eh_frame within some other memory section
(it will be in "load11" or something).  The same changes are trivial to
make to new code given the machinery for grokking .eh_frame format and its
pointer encodings.

With that, I think that finding vsyscall unwind info from core dumps is
accomplished just by making an objfile for the core file bfd and plugging
it into the unwind info grokking hooks or making it a symfile or something.
The part I don't know off hand how to do is making sure the objfile/symfile
comes and goes appropriately with attaching/detaching from a core dump.  
I presume that is straightforward for those better versed in gdb.

As it stands now, the vsyscall DSO has normal section headers.  So matching
".eh_frame" or ".eh_frame_hdr" by name in that special bfd is adequate.  If
it (or other DSOs) were fully stripped, then having bfd fake named sections
for these bfds as it does for ELF core file bfds would be sufficient to
trivially handle those as well.

> 2. Write a symbol reader that uses the run-tume dynamic linker (struct
>    r_debug, struct link_map) to locate the dynamic section of the
>    shared object, and uses it to read the relevant loaded sections of
>    the DSO from the target and interpret those bits.
> 
> If I'm not mistaken, the latter would also allow us to construct a
> minimal symbol table for DSO's even if the we don't have access to an
> on-disk file.  

Indeed so!  Or even if you just have a completely stripped ELF DSO on disk.
(Or even if you just get so tired of turning off auto-solib-add and using
add-symbol-file, and cursing its inability to add .text's vma to the
loadbase itself so you don't have to run objdump -h every damn time,
umpty-ump times a day debugging subhurds, that you just break down and
implement solib-absolute-prefix and become a compulsive maniac to keep
development and test filesystems synchronized!  Oh, I guess that won't
exactly be happening to anyone else in the future. ;-)

This is roughly the same as what I had thought would be the better
long-term plan than the above section-matching.  However, I would separate
it into two pieces.  I would still advocate using a special case mechanism
to find the vsyscall DSO's ELF header and locate its guts from there.  That
works even if the run-tomb dynamic linker's data structures are mangled or
missing.  But it is cleaner for the reasons above if that works from the
phdrs out (thence quickly to .dynamic) only, and doesn't rely on finding
section headers in the DSO.

Whether you use dynamic linker data structures or other magic to locate a
DSO's .dynamic section in memory, from there the procedure is the same to
locate its dynamic symbol table.

> We'll probably need some serious hacking on GDB's shared library support
> to make this all possible.

Not necessarily.  It's straightforward to locate the dynamic symbol table
and its string table by reading the .dynamic section, then copy them out of
the inferior and interpret the ELF symbol table format as we already do.
There are two ways to attack it.  One is to read the symbol and string
tables and then poke them directly into gdb symbol table form.  The other
approach is to fake a bfd containing .dynsym and .dynstr sections, plug
that in as an implicit symfile something like how separate debug info files
are attached along with the stripped objfiles they correspond to, and let
the existing infrastructure go to town.

To support everything we have mentioned, these are the steps I would take:

* Soup up the section-faking code now applied to core dumps so that it not
  only creates the dynamic* section but reads its contents to locate and
  fake sections called .dynsym et al.  Then if we treat a core dump as a
  symfile, it will provide the vsyscall DSO's symbols.  If we apply this
  section-faking code to all sectionless ELF files, then fully-stripped
  DSOs will be supported just as DSO's from binutils strip are now.

* For the vsyscall DSO, we read its ELF header from the inferior.  If it
  has section headers as it does now, we can calculate the total file image
  size to include those, fake a bfd containing the whole image, and all the
  existing support for an ELF DSO works (symbols and all).  If it doesn't
  have section headers, or we decide to ignore them, then we use only the
  file's PT_LOAD phdr to read the runtime memory image.  In that case, the
  section-faking code needs to apply to this synthesized bfd both to find
  .eh_frame_hdr via PT_GNU_EH_FRAME (or .IA64_unwind via PT_IA_64_UNWIND)
  and to find dynamic symbols via PT_DYNAMIC.

* For normal DSOs when you can't find the file on disk (or don't want to
  use it; there should probably be a new variant of auto-solib-add to
  control reading symbols from the inferior image as well as disk files),
  you can straightforwardly get the .dynamic section's address from the
  dynamic linker.  You can copy that from the inferior and from it know the
  locations of the .dynsym and .dynstr sections and copy them as well,
  putting it all into a synthesized bfd with those section names faked.
  There is no "proper" way to locate the phdrs, which you need to find the
  .eh_frame information.  However, in practice you can often assume that
  the loadbase (l_addr) points at the shared object's ELF header, and you
  can verify this by reading that memory and sanity-checking the ELF header
  format.  If you do that, you have all the phdrs and can use the PT_LOAD
  headers to fill out the solib bounds normally gotten from the disk file.
  However, prelinked DSOs may not make it easy to find the ELF header
  (l_addr is zero).

These latter ideas (everything from the quoted #2 on) are of secondary
concern.  I went into complete detail about them now only because you
brought it up.  Symbols from the vsyscall DSO in a core dump are nice, but
not essential.  Getting details from normal DSOs without using disk files
is a new feature that is very nice but not necessary, nor related except in
implementation details, to supporting vsyscall stuff.  The steps above are
not part of my immediate goals.

The essential need is to get .eh_frame information from the vsyscall DSO in
both live processes and core dumps.  The section-faking code already
suffices for core dumps.  For the time being, the image provided by the
kernel does have section headers, so it suffices just to synthesize a bfd
containing the whole file image read out of a live inferior's memory.  My
immediate goal is to get things working just using this.  Other things we
can see about later.  For this immediate goal, I would take these steps:

1. Make dwarf-frame.c work with .eh_frame info.  Mark is working on this,
   so I will wait for him or help with getting it done.

2. Make dwarf-frame.c locate .eh_frame via .eh_frame_hdr, matching a section
   named "eh_frame_hdrNN" as core dumps now have.  
   This is pretty trivial after step 1.

3. Modify corelow.c to do something like symbol_add_file with the core bfd.
   If that barfs on some backends, it could be done just for ELF cores.  I
   don't think it needs to be put into a Linux-specific module; if any
   other ELF core files contain useful phdrs they will work the same way.
   It also needs to remove the objfile/symfile again when the core file is
   detached.  On this I could use advice from those more expert on gdb.  I
   think it may suffice to call symbol_file_add on the core file name in
   place of opening the bfd directly, store the objfile pointer somewhere,
   and call free_objfile in core_detach.  But that is only a guess.  I can
   write this bit and observe internally that it works independent of the
   steps above that make it useful, so immediate implementation advice is
   solicited.

4. Write a function that creates an in-memory bfd by reading an ELF header
   and the information it points to from inferior memory.  I'll take a
   whack at this soon.

5. Write Linux backend code to locate the vsyscall DSO's ELF header, use
   that function to synthesize a bfd, and so something like symbol_add_file
   with it.  I'm not sure where this belongs.  It will be Linux-specific
   but not necessarily machine-dependent.  Where it belongs exactly
   probably depends on how exactly the locating is done.  The need to
   attach and detach the synthesized objfile is similar to the core file case.

Heretofore I have avoided mentioning how we locate the vsyscall DSO's ELF
header in the inferior's address space.  It's an unresolved question that
needs discussion, but it's a minor and boring detail among all the issues
involved here.  I saved it for those with the proven stamina to get through
the first 200 lines of my ranting.

The kernel tells the running process itself where to find the vsyscall DSO
image with an ElfNN_auxv_t element of type AT_SYSINFO_EHDR in the aux
vector it writes at the base of the stack at process startup.  For gdb to
determine this value, there are several approaches possible.

* Add a ptrace request just for it, i.e. PTRACE_GETSYSINFO_EHDR or
  something.  That is trivial to add on the kernel side, and easy for
  native Linux backend code to use.  It just seems sort of unsightly.
  A way to get that address from some /proc/PID file would be equivalent.

* Locate the address of the aux vector and read it out the inferior's
  stack.  The aux vector is placed on the stack just past the environment
  pointers.  AFAIK, gdb doesn't already have a way to know this stack
  address.  It's simple to record it in the kernel without significant new
  overhead, and have a way via either ptrace or /proc to get this address.
  I raise this suggestion because it may be most acceptable to the Linux
  kernel folks to add something with so little kernel work involved.  The
  problem with this is that the program might have clobbered its stack.
  glibc doesn't ordinarily modify it, but a buggy program might clobber it
  by random accident, and any program is within its rights to reuse that
  part of the stack.  It won't have done so at program startup, but if you
  attach to a live process that has clobbered this part of its stack then
  you won't find the vsyscall info so as to unwind from those PCs properly.
  I am curious what gdb hackers' opinions on this danger are.

* Add a way to get the original contents of the aux vector, like
  /proc/PID/auxv on Solaris.  That could be /proc/PID/auxv, or new ptrace
  requests that act like the old PIOCNAUXV and PIOCAUXV.  On Solaris,
  /proc/PID/auxv's contents are not affected by PID clobbering the auxv on
  its stack.  In Linux, about half of the auxv entries are constants the
  kernel can easily fill in anew on the fly, but the other half are
  specific bits about the executable that are not easy to recover later
  from other saved information.  Though AT_SYSINFO_EHDR is all we need, a
  general interface like this really should give the complete set that was
  given to the process.  By far the simplest way to implement that is
  simply to save the array in the kernel.  As the kernel code is now, I can
  do that without any additional copying overhead, but it does add at least
  34 words to the process data structure, which Linux kernel people might
  well reject.  Of these three options, this one is my preference on
  aesthetic grounds but I don't know whether it will happen on the kernel side.

I have not been able to imagine any way to get this magic address (the
vsyscall DSO loadbase) directly from the system that does not require a
special backend call and therefore cause some kind of new headache for
remote debugging.  I don't know what people's thinking is on trying to
translate this kind of thing across the remote protocol.

There is also the option to punt trying to find it directly from the
system, and rely on the dynamic linker's data structures to locate it.  As
mentioned above, I don't like relying on the inferior's data structures not
being frotzed, nor relying on there being a normal dynamic linker to be
able know about the vsyscall DSO.  Furthermore, the normal dynamic linker
report of l_addr is not helpful because that "loadbase" is the bias
relative to the addresses in the DSO's phdrs, which is 0 for the vsyscall
DSO since it is effectively prelinked.  The only address directly available
is l_ld, the address of its .dynamic section.  There is no proper way from
that to locate the phdrs or ELF file header, so it would have to be some
kludge rounding down or searching back from there or something.  The only
thing favoring this approach is that it requires no new target interfaces
and no new remote debugging complications.

I think this question is pretty open, though not all that exciting.  My
inclination is to implement /proc/PID/auxv (with storage overhead) and see
what the Linux kernel hackers' reaction to that is.  They may suggest that
it work by reading out of the process stack (which is what
/proc/PID/cmdline and /proc/PID/environ do).  I would like to know opinions
from the gdb camp on how bad a thing to do that might be.  Second choice is
ot make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way;
that is likely to go over well enough with the kernel hackers.  I would be
all for an entirely different solution that is both robust (not relying on
the inferior's own fungible memory) and remote-friendly, if anyone thinks
of one.


I have raised a lot of crapola in this message.  I hope I have been clear
in specifying the details on which I need some assistance and direction.
Aside from the DWARF2 CFI stuff per se, I am prepared to write all the
necessary code myself and am only soliciting for advice, not for anyone
else to implement it.


Thanks,
Roland

Re: gdb support for Linux vsyscall DSO

[Andrew Cagney]

Roland,

How exactly does this vsyscall memory region(1) come to be?  For 
instance, how does GLIBC come to know where it is - GLIBC would need the 
region's address to perform a syscall to find the regions address.  If 
the underlying mechanism is explained (this is far from a tranditional 
lib*.so), GDB developers will be in a better position to judge the best 
way of handling this.

Is there, for instance, anything to prevent GDB locating the symbol (in 
GLIBC) that points at the vsyscall area and then using that?  Similar 
for any mapped in eh_frame region.  Assuming that GDB has a well defined 
trigger point for knowing when the symbol can be referenced - but GDB 
would need that anyway.

This would eliminate the need to store all this elf header stuff in the 
Kernel, let GDB confine any changes to a single linux-tdep.c file, and 
even work remotely or with a core file.

However, before anyone tries to run with such ideas, what's really going on?

enjoy,
Andrew

Re: gdb support for Linux vsyscall DSO

[Mark Kettenis]

   Date: Sat, 10 May 2003 00:07:07 -0700
   From: Roland McGrath <roland@redhat.com>

   It's notable that I didn't say i386 in the subject.  I am helping David
   Mosberger implement the same concept on ia64 in Linux 2.5 as well.  When
   glibc starts using those entry points on Linux/ia64 (it doesn't yet), then
   there will be the same issues for getting at the unwind info.  The vsyscall
   DSO plan will be the same, so getting at the ELF sections is addressed the
   same way (more on that below).  In the ia64 case, the unwind info is ia64's
   flavor rather than DWARF2 flavor, but the use of ELF phdrs and sections to
   locate it is precisely analogous.

Thanks for your detailed explanation.

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.

   > It certainly is my intention to make it possible, although It's not
   > clear how things should be glued together.  

   As you might imagine, I had thought through most of the details of what gdb
   needs to do when I made the kernel changes (whose main purpose for me was
   to make the gdb support possible).  There are two cases that need to be
   addressed.  You've brought up the case of live processes.  There is also
   the case of core dumps.

   > I've seen your kernel patches and it seems as if there are two
   > possibilities:

   You omitted possibility #0, which I had intended to preemptively describe
   and explain why I rejected it.  That is, to have some file that gdb can
   read.  It would be simple to have a /proc file that gives you the DSO image
   as a virtual file, and have the dynamic linker's shlib list refer to this
   file name.  Then gdb might not need any change at all.  However, this sucks
   rocks for remote debugging.  It also doesn't sit right with me because the
   vsyscall DSO is actually there and your PC might be in it, even if you are
   not using the dynamic linker or glibc at all and have no "info shared" list.

Yup, that's why I didn't mention it :-).

   > 1. Reading the complete DSO from target memory, and somehow turning it
   >    in a bfd.  That would make it possible to use the existing symbol
   >    reading machinere to read symbols and .eh_frame info.

   This is what I had anticipated doing, at least the first cut.  Given some
   true assumptions about the vsyscall DSO, it is trivial to compute the total
   file size from the ELF headers and recover the byte image of the file
   exactly.  It can't be too hard to fake up a bfd in memory as if the
   contents had been read from a file.

Fair enough.

   [...]

   > 2. Write a symbol reader that uses the run-tume dynamic linker (struct
   >    r_debug, struct link_map) to locate the dynamic section of the
   >    shared object, and uses it to read the relevant loaded sections of
   >    the DSO from the target and interpret those bits.
   > 
   > If I'm not mistaken, the latter would also allow us to construct a
   > minimal symbol table for DSO's even if the we don't have access to an
   > on-disk file.  

   Indeed so!  Or even if you just have a completely stripped ELF DSO on disk.
   (Or even if you just get so tired of turning off auto-solib-add and using
   add-symbol-file, and cursing its inability to add .text's vma to the
   loadbase itself so you don't have to run objdump -h every damn time,
   umpty-ump times a day debugging subhurds, that you just break down and
   implement solib-absolute-prefix and become a compulsive maniac to keep
   development and test filesystems synchronized!  Oh, I guess that won't
   exactly be happening to anyone else in the future. ;-)

   This is roughly the same as what I had thought would be the better
   long-term plan than the above section-matching.  However, I would separate
   it into two pieces.  I would still advocate using a special case mechanism
   to find the vsyscall DSO's ELF header and locate its guts from there.  That
   works even if the run-tomb dynamic linker's data structures are mangled or
   missing.  But it is cleaner for the reasons above if that works from the
   phdrs out (thence quickly to .dynamic) only, and doesn't rely on finding
   section headers in the DSO.

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

   [...]

   These latter ideas (everything from the quoted #2 on) are of secondary
   concern.  I went into complete detail about them now only because you
   brought it up.  Symbols from the vsyscall DSO in a core dump are nice, but
   not essential.  Getting details from normal DSOs without using disk files
   is a new feature that is very nice but not necessary, nor related except in
   implementation details, to supporting vsyscall stuff.  The steps above are
   not part of my immediate goals.

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

Note that symbols from the vsyscall would be very helpful to the user.
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 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 essential need is to get .eh_frame information from the vsyscall DSO in
   both live processes and core dumps.  The section-faking code already
   suffices for core dumps.  For the time being, the image provided by the
   kernel does have section headers, so it suffices just to synthesize a bfd
   containing the whole file image read out of a live inferior's memory.  My
   immediate goal is to get things working just using this.  Other things we
   can see about later.  For this immediate goal, I would take these steps:

   1. Make dwarf-frame.c work with .eh_frame info.  Mark is working on this,
      so I will wait for him or help with getting it done.

I just checked something in.  It could use a few more comments, and
certainly needs to be tested, but the basic support for .eh_frame
sections is there.

   2. Make dwarf-frame.c locate .eh_frame via .eh_frame_hdr, matching a section
      named "eh_frame_hdrNN" as core dumps now have.  
      This is pretty trivial after step 1.

   3. Modify corelow.c to do something like symbol_add_file with the core bfd.
      If that barfs on some backends, it could be done just for ELF cores.  I
      don't think it needs to be put into a Linux-specific module; if any
      other ELF core files contain useful phdrs they will work the same way.
      It also needs to remove the objfile/symfile again when the core file is
      detached.  On this I could use advice from those more expert on gdb.  I
      think it may suffice to call symbol_file_add on the core file name in
      place of opening the bfd directly, store the objfile pointer somewhere,
      and call free_objfile in core_detach.  But that is only a guess.  I can
      write this bit and observe internally that it works independent of the
      steps above that make it useful, so immediate implementation advice is
      solicited.

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.

   4. Write a function that creates an in-memory bfd by reading an ELF header
      and the information it points to from inferior memory.  I'll take a
      whack at this soon.

   5. Write Linux backend code to locate the vsyscall DSO's ELF header, use
      that function to synthesize a bfd, and so something like symbol_add_file
      with it.  I'm not sure where this belongs.  It will be Linux-specific
      but not necessarily machine-dependent.  Where it belongs exactly
      probably depends on how exactly the locating is done.  The need to
      attach and detach the synthesized objfile is similar to the core file
      case.

   Heretofore I have avoided mentioning how we locate the vsyscall DSO's ELF
   header in the inferior's address space.  It's an unresolved question that
   needs discussion, but it's a minor and boring detail among all the issues
   involved here.  I saved it for those with the proven stamina to get through
   the first 200 lines of my ranting.

I made it hrough ;-).

   The kernel tells the running process itself where to find the vsyscall DSO
   image with an ElfNN_auxv_t element of type AT_SYSINFO_EHDR in the aux
   vector it writes at the base of the stack at process startup.  For gdb to
   determine this value, there are several approaches possible.

   * Add a ptrace request just for it, i.e. PTRACE_GETSYSINFO_EHDR or
     something.  That is trivial to add on the kernel side, and easy for
     native Linux backend code to use.  It just seems sort of unsightly.
     A way to get that address from some /proc/PID file would be equivalent.

   * Locate the address of the aux vector and read it out the inferior's
     stack.  The aux vector is placed on the stack just past the environment
     pointers.  AFAIK, gdb doesn't already have a way to know this stack
     address.  It's simple to record it in the kernel without significant new
     overhead, and have a way via either ptrace or /proc to get this address.
     I raise this suggestion because it may be most acceptable to the Linux
     kernel folks to add something with so little kernel work involved.  The
     problem with this is that the program might have clobbered its stack.
     glibc doesn't ordinarily modify it, but a buggy program might clobber it
     by random accident, and any program is within its rights to reuse that
     part of the stack.  It won't have done so at program startup, but if you
     attach to a live process that has clobbered this part of its stack then
     you won't find the vsyscall info so as to unwind from those PCs properly.
     I am curious what gdb hackers' opinions on this danger are.

   * Add a way to get the original contents of the aux vector, like
     /proc/PID/auxv on Solaris.  That could be /proc/PID/auxv, or new ptrace
     requests that act like the old PIOCNAUXV and PIOCAUXV.  On Solaris,
     /proc/PID/auxv's contents are not affected by PID clobbering the auxv on
     its stack.  In Linux, about half of the auxv entries are constants the
     kernel can easily fill in anew on the fly, but the other half are
     specific bits about the executable that are not easy to recover later
     from other saved information.  Though AT_SYSINFO_EHDR is all we need, a
     general interface like this really should give the complete set that was
     given to the process.  By far the simplest way to implement that is
     simply to save the array in the kernel.  As the kernel code is now, I can
     do that without any additional copying overhead, but it does add at least
     34 words to the process data structure, which Linux kernel people might
     well reject.  Of these three options, this one is my preference on
     aesthetic grounds but I don't know whether it will happen on the kernel
     side.

   I have not been able to imagine any way to get this magic address (the
   vsyscall DSO loadbase) directly from the system that does not require a
   special backend call and therefore cause some kind of new headache for
   remote debugging.  I don't know what people's thinking is on trying to
   translate this kind of thing across the remote protocol.

   There is also the option to punt trying to find it directly from the
   system, and rely on the dynamic linker's data structures to locate it.  As
   mentioned above, I don't like relying on the inferior's data structures not
   being frotzed, nor relying on there being a normal dynamic linker to be
   able know about the vsyscall DSO.  Furthermore, the normal dynamic linker
   report of l_addr is not helpful because that "loadbase" is the bias
   relative to the addresses in the DSO's phdrs, which is 0 for the vsyscall
   DSO since it is effectively prelinked.  The only address directly available
   is l_ld, the address of its .dynamic section.  There is no proper way from
   that to locate the phdrs or ELF file header, so it would have to be some
   kludge rounding down or searching back from there or something.  The only
   thing favoring this approach is that it requires no new target interfaces
   and no new remote debugging complications.

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.  To avoid kludging around one could:

1. Expose l_phdr in `struct link_map'.

2. Add a field to `struct r_debug'.

3. Add a dynamic tag.  Since the vsyscall DSO is prelinked, I suppose
   this tag could be initailized correctly in the in-kernel image, and
   wouldn't need to be modified by the run-time dynamic linker.  One
   could even consider abusing DT_DEBUG for this purpose.

   I think this question is pretty open, though not all that exciting.  My
   inclination is to implement /proc/PID/auxv (with storage overhead) and see
   what the Linux kernel hackers' reaction to that is.  They may suggest that
   it work by reading out of the process stack (which is what
   /proc/PID/cmdline and /proc/PID/environ do).  I would like to know opinions
   from the gdb camp on how bad a thing to do that might be.  Second choice is

Well, a buffer overflow of a buffer allocated on the stack is a fairly
common problem, and it is not unimaginable that it overwrites auxv.  I
think it is much more likely that this happens than unintentionally
overwriting the dynamic linker data structures since IIRC those data
structures are not allocated from the standard heap.

   ot make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way;
   that is likely to go over well enough with the kernel hackers.  I would be

That would probably be better that reading /proc/PID/auxv out of the
process stack.

   all for an entirely different solution that is both robust (not relying on
   the inferior's own fungible memory) and remote-friendly, if anyone thinks
   of one.

Mark

Re: gdb support for Linux vsyscall DSO

[Daniel Jacobowitz]

On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote:
> Roland,
> 
> How exactly does this vsyscall memory region(1) come to be?  For 
> instance, how does GLIBC come to know where it is - GLIBC would need the 
> region's address to perform a syscall to find the regions address.  If 
> the underlying mechanism is explained (this is far from a tranditional 
> lib*.so), GDB developers will be in a better position to judge the best 
> way of handling this.

It's created initially by the kernel, and its address is passed via the
auxilliary vector on the stack, and read by ld.so.  Roland explained
later in his essay about some ways to get at the aux vector.

> Is there, for instance, anything to prevent GDB locating the symbol (in 
> GLIBC) that points at the vsyscall area and then using that?  Similar 
> for any mapped in eh_frame region.  Assuming that GDB has a well defined 
> trigger point for knowing when the symbol can be referenced - but GDB 
> would need that anyway.
> 
> This would eliminate the need to store all this elf header stuff in the 
> Kernel, let GDB confine any changes to a single linux-tdep.c file, and 
> even work remotely or with a core file.

The down side is that this is then glibc specific... the mechanism
isn't glibc's.  I think that's Roland's intention at least.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

For some reason I didn't see Andrew's message in my mailbox, though I see
it in the mailing list archives (I'm not on the mailing list myself).


> On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote:
> > Roland,
> > 
> > How exactly does this vsyscall memory region(1) come to be?  For 
> > instance, how does GLIBC come to know where it is - GLIBC would need the 
> > region's address to perform a syscall to find the regions address.  If 
> > the underlying mechanism is explained (this is far from a tranditional 
> > lib*.so), GDB developers will be in a better position to judge the best 
> > way of handling this.
> 
> It's created initially by the kernel, and its address is passed via the
> auxilliary vector on the stack, and read by ld.so.  Roland explained
> later in his essay about some ways to get at the aux vector.

The memory is always there.  As I explained near the end of my long
message, the kernel tells the program where to find it with the
AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the
aux vector on the stack at at startup.

The glibc dynamic linker code sets up its own data structures for the
vsyscall DSO as if it had been mapped itself.  There is no special case in
glibc that points at the eh_frame info.  Exception handling in libgcc
already uses a dynamic linker callback to see the phdrs of all DSOs in core
and follow their PT_GNU_EH_FRAME pointers.  The vsyscall DSO's eh_frame
info is found by this mechanism like other DSOs' are.  

> > Is there, for instance, anything to prevent GDB locating the symbol (in 
> > GLIBC) that points at the vsyscall area and then using that?  Similar 
> > for any mapped in eh_frame region.  Assuming that GDB has a well defined 
> > trigger point for knowing when the symbol can be referenced - but GDB 
> > would need that anyway.

Nothing prevents it but class.  The vsyscall DSO is a Linux kernel feature,
not a glibc feature.  It isn't proper layering for the support for it to
depend on glibc internals.  There are any number of things that could be
done simpler by presuming the form of glibc internals and requiring they be
there.  That doesn't make them the right things to do.


I said "the purpose of the vsyscall DSO for me is to make the gdb support
possible".  Perhaps that gave the wrong impression.  The gdb issue is what
made me personally really interested in implementing it, but was only one
of many factors leading to the choice of having an ELF DSO image provided
by the kernel.  The DSO plan is here to stay and does not exist solely for
the benefit of gdb.


Thanks,
Roland

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

> 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.

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

Btw, I did get this msg from Andrew, just delayed a few hours.

Re: gdb support for Linux vsyscall DSO

[Andrew Cagney]

>> On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote:
> 
>> > Roland,
>> > 
>> > How exactly does this vsyscall memory region(1) come to be?  For 
>> > instance, how does GLIBC come to know where it is - GLIBC would need the 
>> > region's address to perform a syscall to find the regions address.  If 
>> > the underlying mechanism is explained (this is far from a tranditional 
>> > lib*.so), GDB developers will be in a better position to judge the best 
>> > way of handling this.
> 
>> 
>> It's created initially by the kernel, and its address is passed via the
>> auxilliary vector on the stack, and read by ld.so.  Roland explained
>> later in his essay about some ways to get at the aux vector.
> 
> 
> The memory is always there.  As I explained near the end of my long
> message, the kernel tells the program where to find it with the
> AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the
> aux vector on the stack at at startup.
> 
> The glibc dynamic linker code sets up its own data structures for the
> vsyscall DSO as if it had been mapped itself.  There is no special case in
> glibc that points at the eh_frame info.  Exception handling in libgcc
> already uses a dynamic linker callback to see the phdrs of all DSOs in core
> and follow their PT_GNU_EH_FRAME pointers.  The vsyscall DSO's eh_frame
> info is found by this mechanism like other DSOs' are.  
> 
> 
>> > Is there, for instance, anything to prevent GDB locating the symbol (in 
>> > GLIBC) that points at the vsyscall area and then using that?  Similar 
>> > for any mapped in eh_frame region.  Assuming that GDB has a well defined 
>> > trigger point for knowing when the symbol can be referenced - but GDB 
>> > would need that anyway.
> 
> 
> Nothing prevents it but class.  The vsyscall DSO is a Linux kernel feature,
> not a glibc feature.  It isn't proper layering for the support for it to
> depend on glibc internals.  There are any number of things that could be
> done simpler by presuming the form of glibc internals and requiring they be
> there.  That doesn't make them the right things to do.

It doesn't make it the wrong thing to do either.  As they say, keep it 
simple.  What was posted was a worryingly long list of changes for 
something that should be relatively straight forward - find the eh-frame 
stuff and use it.

Any way, re-reading your post yes, the info is in there.  If the address 
is known, GDB can pull the contents out of memory.  Given the list of 
targets:

- core
- native attach
- native run
- remote
- ?more?

I believe the choices are:

- find a way of determing that address across all of these targets :-/
- implement per-target custom mechanisms for pulling out this 
information (creating a need to test/implement each target separatly - 
vis the corefile + dwarf2 changes) :-//

So, it possible to find the address (symbol?, /proc, shlib load table, 
...?) for all targets?

/proc/PID/map, on a remote, is a possability.  A remote version of 
find_memory_regions() would be useful anyway - clean up gcore a bit. 
However, the down side is that a system with no /proc mounted wouldn't 
debug very well :-/

Andrew

Re: NPTL thread support

[H. J. Lu]

On Fri, May 09, 2003 at 12:31:42PM -0400, Elena Zannoni wrote:
> 
> All the patches have been posted by Jeff Johnston to the gdb-patches list.
> I think in the last 2 months or so. They should still apply cleanly.
> 
> If you try them, could you post to the list how it went?
> 
> elena
> 

I tried those patches. Gdb compiled ok. But "make check" never finished
under RedHat 9. I got

FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
FAIL: gdb.base/selftest.exp: step into xmalloc call
FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
FAIL: gdb.java/jmisc.exp: ptype jmisc
FAIL: gdb.java/jmisc.exp: p args
FAIL: gdb.java/jmisc.exp: p *args
FAIL: gdb.java/jmisc1.exp: ptype jmisc
FAIL: gdb.java/jmisc2.exp: ptype jmisc
FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
FAIL: gdb.objc/basicclass.exp: breakpoint method
FAIL: gdb.objc/basicclass.exp: breakpoint method with colon
FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon
FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning
FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
FAIL: gdb.objc/basicclass.exp: print an ivar of self
FAIL: gdb.objc/basicclass.exp: print self
FAIL: gdb.objc/basicclass.exp: print contents of self
FAIL: gdb.objc/basicclass.exp: breakpoint in category method
FAIL: gdb.objc/basicclass.exp: continue until category method
FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments
FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument
FAIL: gdb.objc/basicclass.exp: Use of the print-object command
FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command
FAIL: gdb.threads/gcore-thread.exp: thread 2 is running (timeout)
FAIL: gdb.threads/gcore-thread.exp: save a corefile (timeout)
FAIL: gdb.threads/gcore-thread.exp: re-load generated corefile (file not found)
FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout)
FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 1
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 2 (timeout)
FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 2
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 3 (timeout)
FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 3
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 4 (timeout)
FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 4
FAIL: gdb.threads/linux-dp.exp: list linux-dp.c:1,1 (timeout)
FAIL: gdb.threads/linux-dp.exp: find line number containing "linuxthreads.exp: info threads 2" (timeout)
FAIL: gdb.threads/linux-dp.exp: setting breakpoint at -1 (timeout)
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: main thread's sleep (timeout)
FAIL: gdb.threads/linux-dp.exp: info threads 2 (timeout)
FAIL: gdb.threads/linux-dp.exp: setting breakpoint at print_philosopher thread 5 (timeout)
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print (timeout)
FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit (timeout)
FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print, pass: 0 (timeout)
FAIL: gdb.threads/linux-dp.exp: thread-specific breakpoint is thread-specific (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 1 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 1 (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 2 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2 (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 3 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 3 (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 4 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 4 (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 5 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 5 (timeout)
FAIL: gdb.threads/linux-dp.exp: selected thread: 6 (timeout)
FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6 (timeout)
FAIL: gdb.threads/linux-dp.exp: found an interesting thread
FAIL: gdb.threads/print-threads.exp: Running threads (slow) (timeout)
FAIL: gdb.threads/print-threads.exp: Running threads (slow with kill breakpoint) (timeout)
FAIL: gdb.threads/pthreads.exp: Continue to creation of second thread (timeout)
FAIL: gdb.threads/pthreads.exp: set var common_routine::hits=0 (timeout)
FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread1=0 (timeout)
FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread2=0 (timeout)
FAIL: gdb.threads/pthreads.exp: set var common_routine::from_main=0 (timeout)
FAIL: gdb.threads/pthreads.exp: set var common_routine::full_coverage=0 (timeout)
FAIL: gdb.threads/pthreads.exp: disable (timeout)
FAIL: gdb.threads/pthreads.exp: tbreak common_routine if hits >= 15 (timeout)
FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times

and the lat 2 lines in gdb.log are

FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times
PASS: gdb.threads/pthreads.exp: Continue with all threads running



H.J.

Re: gdb support for Linux vsyscall DSO

[Mark Kettenis]

   Date: Sat, 10 May 2003 13:27:20 -0700
   From: Roland McGrath <roland@redhat.com>

   > 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.

Careless thinking of me; of course one should prefer the most reliable
method.  I fully agree with you here.

   > 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.)

There is some special handling for signal trampolines in
infrun.c:handle_inferior_event().  Beware!  Dragons can still be found
in that function.  However, it seems the bit of code I'm talking about
is there for targets that don't known how to properly unwind signal
frames :-).

There is also the issue of unwinding interrupted frames vs. called
frames, where we substract 1 from the return address to get an address
in the middle of the call instruction that is in progress.  But rth
has taken care of that.

   > 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).  

Restoring %eflags is certainly possible.  Making GDB actually pop the
signal trampoline frame should work, but could lead to "interesting"
behaviour.  I mean, the kernel will still think the program has taken
a signal.  Hmm, looking at both the FreeBSD and Linux kernels it seems
as if only the signal mask might be incorrect.

   > 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.

Well, for processes started by GDB we can read the auxiliary vector
from the pristine stack, but that doesn't work for attached-to
processes.

   > 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.

Well, extending the structure shouldn't pose a problem, although there
is some risk.  The origional link.h contained the following comment:

   /* Structure describing...

   ...

   This data structure might change in future, if necessary.  User-level
   programs must avoid defining objects of this type.  */

But those last two sentences have been removed from the link.h that's
actually installed.

   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.

Given that we know where the dynamic section is from l_ld, I think we
can figure out all we need to know from there.  I used the linker
script from Linux 2.5.69 to generate a vsyscall-int80.so, and I'm
seeing the location of all relevant sections in the symbol table.  Is
it possible to re-order the sections such that .dynamic comes a bit
earlier than now?  In that case (l_ld & 0xfffff000) would almost
certainly be the address of the ELF header.

Mark

Re: gdb support for Linux vsyscall DSO

[Andrew Cagney]

> Any way, re-reading your post yes, the info is in there.  If the address is known, GDB can pull the contents out of memory.  Given the list of targets:
> 
> - core
> - native attach
> - native run
> - remote
> - ?more?
> 
> I believe the choices are:
> 
> - find a way of determing that address across all of these targets :-/
> - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-//
> 
> So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets?
> 
> /proc/PID/map, on a remote, is a possability.  A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/

To follow up my own e-mail.  On Solaris, there is:

	/proc/PID/auxv

and the corresponding core file includes a .note section that contains 
(man core.4):

      auxv_t array
            n_type: NT_AUXV. This  entry  contains  the  array  of
            auxv_t  structures  that  was  passed by the operating
            system as startup information to the  dynamic  linker.
            Auxiliary    vector    information   is   defined   in
            <sys/auxv.h>.

So the /proc solution even as ``prior art''.

As for the remote case, I think GDB's remote protocol (via the target 
vector) should allow access to the remote file system (lib*.so, /proc, 
....) anyway.  Doing that would let the OS dependant code access the 
remote /proc/PID/aux.  All sorts of useful things would suddenly ``just 
work''.

To me this looks like the simplest and cleanest way of solving the 
problem.  A conistent mechanism to find the address, and a single 
technique for accessing the .eh_frame info.  That has to be better than 
approaches that require per-target custom modifications for what is a 
Linux specific problem.

Andrew

Re: NPTL thread support

[J. Johnston]

H.J.,

   Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1
in config.h?  Can you also confirm that the value: tkill_failed in
lin-lwp.c is not set to true when running the debugger?

-- Jeff J.

H. J. Lu wrote:
> On Fri, May 09, 2003 at 12:31:42PM -0400, Elena Zannoni wrote:
> 
>>All the patches have been posted by Jeff Johnston to the gdb-patches list.
>>I think in the last 2 months or so. They should still apply cleanly.
>>
>>If you try them, could you post to the list how it went?
>>
>>elena
>>
> 
> 
> I tried those patches. Gdb compiled ok. But "make check" never finished
> under RedHat 9. I got
> 
> FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
> FAIL: gdb.base/selftest.exp: step into xmalloc call
> FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
> FAIL: gdb.java/jmisc.exp: ptype jmisc
> FAIL: gdb.java/jmisc.exp: p args
> FAIL: gdb.java/jmisc.exp: p *args
> FAIL: gdb.java/jmisc1.exp: ptype jmisc
> FAIL: gdb.java/jmisc2.exp: ptype jmisc
> FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
> FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
> FAIL: gdb.objc/basicclass.exp: breakpoint method
> FAIL: gdb.objc/basicclass.exp: breakpoint method with colon
> FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon
> FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
> FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning
> FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
> FAIL: gdb.objc/basicclass.exp: print an ivar of self
> FAIL: gdb.objc/basicclass.exp: print self
> FAIL: gdb.objc/basicclass.exp: print contents of self
> FAIL: gdb.objc/basicclass.exp: breakpoint in category method
> FAIL: gdb.objc/basicclass.exp: continue until category method
> FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments
> FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument
> FAIL: gdb.objc/basicclass.exp: Use of the print-object command
> FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command
> FAIL: gdb.threads/gcore-thread.exp: thread 2 is running (timeout)
> FAIL: gdb.threads/gcore-thread.exp: save a corefile (timeout)
> FAIL: gdb.threads/gcore-thread.exp: re-load generated corefile (file not found)
> FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout)
> FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 1
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 2 (timeout)
> FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 2
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 3 (timeout)
> FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 3
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 4 (timeout)
> FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 4
> FAIL: gdb.threads/linux-dp.exp: list linux-dp.c:1,1 (timeout)
> FAIL: gdb.threads/linux-dp.exp: find line number containing "linuxthreads.exp: info threads 2" (timeout)
> FAIL: gdb.threads/linux-dp.exp: setting breakpoint at -1 (timeout)
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: main thread's sleep (timeout)
> FAIL: gdb.threads/linux-dp.exp: info threads 2 (timeout)
> FAIL: gdb.threads/linux-dp.exp: setting breakpoint at print_philosopher thread 5 (timeout)
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print (timeout)
> FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit (timeout)
> FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print, pass: 0 (timeout)
> FAIL: gdb.threads/linux-dp.exp: thread-specific breakpoint is thread-specific (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 1 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 1 (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 2 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2 (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 3 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 3 (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 4 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 4 (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 5 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 5 (timeout)
> FAIL: gdb.threads/linux-dp.exp: selected thread: 6 (timeout)
> FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6 (timeout)
> FAIL: gdb.threads/linux-dp.exp: found an interesting thread
> FAIL: gdb.threads/print-threads.exp: Running threads (slow) (timeout)
> FAIL: gdb.threads/print-threads.exp: Running threads (slow with kill breakpoint) (timeout)
> FAIL: gdb.threads/pthreads.exp: Continue to creation of second thread (timeout)
> FAIL: gdb.threads/pthreads.exp: set var common_routine::hits=0 (timeout)
> FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread1=0 (timeout)
> FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread2=0 (timeout)
> FAIL: gdb.threads/pthreads.exp: set var common_routine::from_main=0 (timeout)
> FAIL: gdb.threads/pthreads.exp: set var common_routine::full_coverage=0 (timeout)
> FAIL: gdb.threads/pthreads.exp: disable (timeout)
> FAIL: gdb.threads/pthreads.exp: tbreak common_routine if hits >= 15 (timeout)
> FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times
> 
> and the lat 2 lines in gdb.log are
> 
> FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times
> PASS: gdb.threads/pthreads.exp: Continue with all threads running
> 
> 
> 
> H.J.
> 

Re: NPTL thread support

[H. J. Lu]

On Mon, May 12, 2003 at 03:20:13PM -0400, J. Johnston wrote:
> H.J.,
> 
>    Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1
> in config.h?  Can you also confirm that the value: tkill_failed in
> lin-lwp.c is not set to true when running the debugger?
> 

It was a pilot error. The "make check" hang is gone. Here are the
failures in today's cvs on RedHat 9.

H.J.
----
FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
FAIL: gdb.base/selftest.exp: step into xmalloc call
FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
FAIL: gdb.java/jmisc.exp: ptype jmisc
FAIL: gdb.java/jmisc.exp: p args
FAIL: gdb.java/jmisc.exp: p *args
FAIL: gdb.java/jmisc1.exp: ptype jmisc
FAIL: gdb.java/jmisc2.exp: ptype jmisc
FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
FAIL: gdb.objc/basicclass.exp: breakpoint method
FAIL: gdb.objc/basicclass.exp: breakpoint method with colon
FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon
FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning
FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
FAIL: gdb.objc/basicclass.exp: print an ivar of self
FAIL: gdb.objc/basicclass.exp: print self
FAIL: gdb.objc/basicclass.exp: print contents of self
FAIL: gdb.objc/basicclass.exp: breakpoint in category method
FAIL: gdb.objc/basicclass.exp: continue until category method
FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments
FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument
FAIL: gdb.objc/basicclass.exp: Use of the print-object command
FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command
FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout)

Re: NPTL thread support

[David Carlton]

On Mon, 12 May 2003 13:08:39 -0700, "H. J. Lu" <hjl@lucon.org> said:

> It was a pilot error. The "make check" hang is gone. Here are the
> failures in today's cvs on RedHat 9.

> FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
> FAIL: gdb.base/selftest.exp: step into xmalloc call
> FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
> FAIL: gdb.java/jmisc.exp: ptype jmisc
> FAIL: gdb.java/jmisc.exp: p args
> FAIL: gdb.java/jmisc.exp: p *args
> FAIL: gdb.java/jmisc1.exp: ptype jmisc
> FAIL: gdb.java/jmisc2.exp: ptype jmisc
> FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
> FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird

These are all normal.  (I can't speak about the gdb.objc ones.)

David Carlton
carlton@math.stanford.edu

Re: NPTL thread support

[Elena Zannoni]

H. J. Lu writes:
 > On Mon, May 12, 2003 at 03:20:13PM -0400, J. Johnston wrote:
 > > H.J.,
 > > 
 > >    Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1
 > > in config.h?  Can you also confirm that the value: tkill_failed in
 > > lin-lwp.c is not set to true when running the debugger?
 > > 
 > 
 > It was a pilot error. The "make check" hang is gone. Here are the
 > failures in today's cvs on RedHat 9.

thanks, that's more reasonable.
(I still have a rewrite of the TLS tests to resubmit...)

elena


 > 
 > H.J.
 > ----
 > FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
 > FAIL: gdb.base/selftest.exp: step into xmalloc call
 > FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
 > FAIL: gdb.java/jmisc.exp: ptype jmisc
 > FAIL: gdb.java/jmisc.exp: p args
 > FAIL: gdb.java/jmisc.exp: p *args
 > FAIL: gdb.java/jmisc1.exp: ptype jmisc
 > FAIL: gdb.java/jmisc2.exp: ptype jmisc
 > FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
 > FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
 > FAIL: gdb.objc/basicclass.exp: breakpoint method
 > FAIL: gdb.objc/basicclass.exp: breakpoint method with colon
 > FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon
 > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
 > FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning
 > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint
 > FAIL: gdb.objc/basicclass.exp: print an ivar of self
 > FAIL: gdb.objc/basicclass.exp: print self
 > FAIL: gdb.objc/basicclass.exp: print contents of self
 > FAIL: gdb.objc/basicclass.exp: breakpoint in category method
 > FAIL: gdb.objc/basicclass.exp: continue until category method
 > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments
 > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument
 > FAIL: gdb.objc/basicclass.exp: Use of the print-object command
 > FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command
 > FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout)

Re: NPTL thread support

[Andrew Cagney]

> On Mon, 12 May 2003 13:08:39 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
> 
>> It was a pilot error. The "make check" hang is gone. Here are the
>> failures in today's cvs on RedHat 9.
> 
> 
>> FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error)
>> FAIL: gdb.base/selftest.exp: step into xmalloc call
>> FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main
>> FAIL: gdb.java/jmisc.exp: ptype jmisc
>> FAIL: gdb.java/jmisc.exp: p args
>> FAIL: gdb.java/jmisc.exp: p *args
>> FAIL: gdb.java/jmisc1.exp: ptype jmisc
>> FAIL: gdb.java/jmisc2.exp: ptype jmisc
>> FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
>> FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
> 
> 
> These are all normal.  (I can't speak about the gdb.objc ones.)

Unless you've got ObjC installed, those are normal as well (it should 
probably be tweaked too, like threads, just fail when the compiler dies).

Andrew

Re: NPTL thread support

[David Carlton]

On Mon, 12 May 2003 17:09:32 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> These are all normal.  (I can't speak about the gdb.objc ones.)

> Unless you've got ObjC installed, those are normal as well (it
> should probably be tweaked too, like threads, just fail when the
> compiler dies).

Whoops, you're right: I thought I was seeing different messages, but I
was seeing those FAILs as well.  I agree that the current failure mode
for gdb.objc is suboptimal.  Though calling gdb_suppress_entire_file
sounds reasonable to me; is there no way to fix it to actually end the
file instead of trying and failing to suppress the tests in the file?

David Carlton
carlton@math.stanford.edu

Re: NPTL thread support

[Daniel Jacobowitz]

On Mon, May 12, 2003 at 02:18:30PM -0700, David Carlton wrote:
> On Mon, 12 May 2003 17:09:32 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> >> These are all normal.  (I can't speak about the gdb.objc ones.)
> 
> > Unless you've got ObjC installed, those are normal as well (it
> > should probably be tweaked too, like threads, just fail when the
> > compiler dies).
> 
> Whoops, you're right: I thought I was seeing different messages, but I
> was seeing those FAILs as well.  I agree that the current failure mode
> for gdb.objc is suboptimal.  Though calling gdb_suppress_entire_file
> sounds reasonable to me; is there no way to fix it to actually end the
> file instead of trying and failing to suppress the tests in the file?

Just say "return 0"?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

> There is some special handling for signal trampolines in
> infrun.c:handle_inferior_event().  Beware!  Dragons can still be found
> in that function.  However, it seems the bit of code I'm talking about
> is there for targets that don't known how to properly unwind signal
> frames :-).

I only partly follow the code in that function, but it does look like it
wants to know whether it's in a signal frame.  I get the impression that
"next" or "step" interrupted by a signal lets the signal be handled and
continues until the end of the source line rather than doing a normal user
stop for the signal, and that this is considered desireable.  So it must know.

Having a DWARF2 extension to mark signal frames seems reasonable, and less
kludgey than matching symbol names.  However, I wonder if there is in fact
a way to do it that won't confuse older libgcc's .eh_frame unwinding code.

> Restoring %eflags is certainly possible.  Making GDB actually pop the
> signal trampoline frame should work

I only mentioned %eflags to pedantic because I caught myself about to say
"restore the exact state of the interrupted thread" and that wasn't
completely true.  I don't anticipate gdb having any reason to want to roll
back a signal frame.  (However, in the abstract it seems like the right
thing for the kernel unwind info to describe restoring %eflags if the
DWARF2 format can already represent that.)

> Well, for processes started by GDB we can read the auxiliary vector from
> the pristine stack, but that doesn't work for attached-to processes.

Good point.  I am inclined to think this is worth doing because, for the
case it covers, it is both fully robust and fully remote-friendly even with
old existing remote stubs, and is easy enough to implement on a per-target
basis.  If a direct inquiry is available, that will still be quicker than
the straightforward but numerous inferior memory reads that must be done to
extract the information from the stack, and so is the first choice; if it's
available for remote too, all the better.  But I think I will implement
this fallback at least for i386, just because it's a 100% correct solution
for at least half the cases (i.e. run but not attach) that can work today
without waiting for the a new kernel feature and/or remote stub upgrades to
be installed.

> Given that we know where the dynamic section is from l_ld, I think we
> can figure out all we need to know from there.

As a special case for the Linux vsyscall DSO, it would be adequate just to
presume it will fit in a single page and round down.  But you've reminded
me that there are other useful addresses to be found by looking in the
.dynamic section itself.  DT_HASH gives the location of the .hash section,
which a normal ld -shared always puts as the first section in the file,
appearing right after the file and program headers.  Without relying on
.hash being first per se, you can reasonably assume that the sections
referenced by DT_* are the first group in the file and so start with the
lowest of those addresses.  Rounding that address down to the smallest of
any actual ELF platform's page size (which might be 4k?) is a pretty darn
reasonable guess for finding the ELF header of any mapped DSO.


Thanks much for all the helpful feedback,
Roland

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

> To follow up my own e-mail.  On Solaris, there is:
> 
> 	/proc/PID/auxv
[...]
> So the /proc solution even as ``prior art''.

Indeed.  When I said, "like /proc/PID/auxv on Solaris", I was in fact
citing the existing Solaris interface as exactly what we might do.
However, as I said and for reasons I explained, we might not get buy-in
from kernel maintainers for supporting that.  I don't think that the prior
art of Solaris interfaces is something they find particularly compelling.

I'm not saying this feature won't happen--I certainly like it fine.  My
intent in starting the thread about the various possible sorts of kernel
interface was to flesh out the full range of acceptable options and their
preference ordering from the gdb perspective, to have on hand when I go and
argue for whichever of them we can get from the kernel maintainers.

> and the corresponding core file includes a .note section that contains 

I'm aware of the Solaris formats (which are all pretty reasonable).  If
Linux kernel maintainers accept the /proc/PID/auxv implementation, then I
am quite sure they will also accept NT_AUXV note writing (the kernel
support required is the same for both).  However, the core note does not
provide any new magic bullet.  There would still be new code required to
grok it; that code is straightforward, but both a bit more complex and a
bit more costly than the core phdr support that is already there now.

> As for the remote case, I think GDB's remote protocol (via the target 
> vector) should allow access to the remote file system (lib*.so, /proc, 
> ....) anyway.  Doing that would let the OS dependant code access the 
> remote /proc/PID/aux.  All sorts of useful things would suddenly ``just 
> work''.

I have nothing against that.  It obviously makes any /proc-based solution
work for remote (requiring /proc be mounted is an issue for both native and
remote).  I assume then that linux-proc.c would be made to use some new
target interface for the file-reading and thus start working via remote.
Then the support for reading either /proc/PID/auxv or /proc/PID/maps to
discern the vsyscall DSO address naturally fits there, machine-independent.

> To me this looks like the simplest and cleanest way of solving the 
> problem.  A conistent mechanism to find the address, and a single 
> technique for accessing the .eh_frame info.  That has to be better than 
> approaches that require per-target custom modifications for what is a 
> Linux specific problem.

As I said before, I am certainly happiest with someplace to put the
kernel-specific support that is not machine-specific.  The support for
using core file phdrs (to sort of treat the core file as if it were the
DSO) is so simple (and already works), that I am inclined to leave that
rather than reading the vsyscall DSO image out of the core file memory dump
after using the NT_AUXV note to locate it.  The code for making a bfd from
the in-memory DSO image is already needed for the live case, so that's not
extra work.  But as well as it being more efficient to use the core file
bfd directly rather than read part of the file into memory and make that
into a separate bfd, it's also simpler, slightly more efficient, and
already done(!), to use the core file's PT_GNU_EH_FRAME (and then you've
got it right there) than to even to look for an NT_AUXV note and the
AT_SYSINFO_EHDR element within it before you can fake up the bfd and search
it for eh_frame.


Thanks,
Roland

Re: gdb support for Linux vsyscall DSO

[Andrew Cagney]

Roland,

There is no silver bullet.

However, there are designs that [I think] provide both GDB and the 
kernel the best of possible worlds.  If the kernel simply dumps out its 
raw information (instead of cooking it in a way it thinks will be useful 
to debuggers) then GDB can pick and choose what it really needs.  This 
also means that the core file and live process are both furnishing GDB 
with identical data.  Might even make the kernel cleaner.

Andrew

Re: gdb support for Linux vsyscall DSO

[Mark Kettenis]

   Date: Mon, 12 May 2003 18:53:16 -0700
   From: Roland McGrath <roland@redhat.com>

   > There is some special handling for signal trampolines in
   > infrun.c:handle_inferior_event().  Beware!  Dragons can still be found
   > in that function.  However, it seems the bit of code I'm talking about
   > is there for targets that don't known how to properly unwind signal
   > frames :-).

   I only partly follow the code in that function, but it does look
   like it wants to know whether it's in a signal frame.  I get the
   impression that "next" or "step" interrupted by a signal lets the
   signal be handled and continues until the end of the source line
   rather than doing a normal user stop for the signal, and that this
   is considered desireable.  So it must know.

I'm not really sure.  The code I referred to seems to be written for
BSD-style signal trampolines, where the signal trampoline will call
the signal handler.  The Linux kernel calls the signal trampoline
directly, so perhaps it doesn't need this code.

   Having a DWARF2 extension to mark signal frames seems reasonable, and less
   kludgey than matching symbol names.  However, I wonder if there is in fact
   a way to do it that won't confuse older libgcc's .eh_frame unwinding code.

If the `z' augmentation doesn't confuse older libgcc's, I don't see
why adding another augmentation would do so.  But we should first
determine if we really need it before adding it.

   > Restoring %eflags is certainly possible.  Making GDB actually pop the
   > signal trampoline frame should work

   I only mentioned %eflags to pedantic because I caught myself about to say
   "restore the exact state of the interrupted thread" and that wasn't
   completely true.  I don't anticipate gdb having any reason to want to roll
   back a signal frame.  (However, in the abstract it seems like the right
   thing for the kernel unwind info to describe restoring %eflags if the
   DWARF2 format can already represent that.)

Well, GDB will do exactly that when the user gives the "return"
command in a signal trampoline.

Mark

Re: gdb support for Linux vsyscall DSO

[Roland McGrath]

> I'm not really sure.  The code I referred to seems to be written for
> BSD-style signal trampolines, where the signal trampoline will call
> the signal handler.  The Linux kernel calls the signal trampoline
> directly, so perhaps it doesn't need this code.

I assume you meant "calls the signal handler directly" here.  I don't know
off hand what other systems do.  Linux does point the PC directly at the
signal handler, but the return address on its stack is the sigreturn code.
So once the handler function is entered, the register and stack state looks
like that code was the caller.

> If the `z' augmentation doesn't confuse older libgcc's, I don't see
> why adding another augmentation would do so.  But we should first
> determine if we really need it before adding it.

Oh, I see.  It hadn't occurred to me you meant an augmentation addition,
and I was thinking of new opcodes or something like that.

> Well, GDB will do exactly that when the user gives the "return"
> command in a signal trampoline.

Does that need to work?  Does it really work now?  (Using "return" in a
signal handler function should work fine, and that is what seems like it
would matter.)