This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Improved linker-debugger interface
> From: Tom Tromey <tromey@redhat.com>
> Date: Mon, 07 May 2012 14:27:27 -0600
>
> Gary> My current setup has a probe everywhere _dl_debug_state is called,
>
> Jan> I believe you should submit the STAP (SystemTap) probes patch to
> Jan> GNU libc along. I do not see too great to patch GNU gdb for a libc
> Jan> feature not in GNU libc.
>
> I don't see that as such a big deal. We have patches in gdb for all
> kinds of system- and compiler-specific behavior. At least in this case
> the patches in question are public and free software.
I think this is a big deal. We can't just add support for every
feature that looks neat into GDB. In the long run, that will lead to
an unmaintainable codebase.
I'm pretty annoyed by the whole SystemTap thing. You presented this
as being something pretty generic. But it turns out this is not only
Linux-specfic, but pretty much a completely RedHat-specific thing it
seems. And I think I've figured out why: SystemTap relies on utrace,
which is not present in the official Linux kernel source tree. And as
far as I can see it will remain that way in the near future. So
unless you are running RedHat Linux, you'll not only need to build a
patched glibc, but you also need to build a patched kernel to be able
to use these new SystemTap probes. Not many people will do that!
Having the basic SystemTap support in GDB is fine. But depending on
it to fix issues with core GDB functionality like the ability to debug
shared libraries is a different matter. It means that people using
RedHat Linux, almost certainly including any RedHat engineers
contributing here will no longer test the codepaths that don't rely on
SystemTap. And people on other Linux variants will never test the
codepaths that rely on SystemTap. That'll inevitably lead to more
breakage.
> I do agree that we should make another attempt to get the probes
> upstream; I just don't think success at that should be a precondition
> for this patch.
If you ask me, having utrace in the official Linux kernel should be a
precondition for this patch as well.
> FWIW, we already have support for the glibc longjmp probes in the tree
> now.
In the glibc tree? Or in the GDB tree? If these probes are not
present in the official glibc tree, the support for those particular
probes should not be in the official GDB tree either.