From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30905 invoked by alias); 9 May 2012 08:12:18 -0000 Received: (qmail 30886 invoked by uid 22791); 9 May 2012 08:12:16 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 08:12:02 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q498BsGQ001050; Wed, 9 May 2012 10:11:54 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q498BqhT006233; Wed, 9 May 2012 10:11:52 +0200 (CEST) Date: Wed, 09 May 2012 08:12:00 -0000 Message-Id: <201205090811.q498BqhT006233@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: tromey@redhat.com CC: mark.kettenis@xs4all.nl, jan.kratochvil@redhat.com, gdb-patches@sourceware.org, gbenson@redhat.com In-reply-to: <8762c6x08n.fsf@fleche.redhat.com> (message from Tom Tromey on Tue, 08 May 2012 07:37:12 -0600) Subject: Re: [RFA] Improved linker-debugger interface References: <20120504152129.GA7418@redhat.com> <20120507165648.GA22472@host2.jankratochvil.net> <87r4uvwxcg.fsf@fleche.redhat.com> <201205072131.q47LVjTN014466@glazunov.sibelius.xs4all.nl> <8762c6x08n.fsf@fleche.redhat.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00259.txt.bz2 > From: Tom Tromey > Date: Tue, 08 May 2012 07:37:12 -0600 > > >>>>> "Mark" == Mark Kettenis writes: > > Mark> I'm pretty annoyed by the whole SystemTap thing. You presented this > Mark> as being something pretty generic. But it turns out this is not only > Mark> Linux-specfic, but pretty much a completely RedHat-specific thing it > Mark> seems. And I think I've figured out why: SystemTap relies on utrace, > Mark> which is not present in the official Linux kernel source tree. And as > Mark> far as I can see it will remain that way in the near future. So > Mark> unless you are running RedHat Linux, you'll not only need to build a > Mark> patched glibc, but you also need to build a patched kernel to be able > Mark> to use these new SystemTap probes. Not many people will do that! > > None of this is the accurate. > > I'm also annoyed now, because I explained all this at length, twice, and > also sent references to the documentation, explaining how the probe > feature is a relatively generic ELF feature, not dependent on the main > body of System Tap at all. Apparently you didn't read any of this. Sorry, but I looked back in my private mail archive and the mailing list archives, and I couldn't find a mail from you with references to documentation. I did some digging around myself, and landed at: which mentions the dependency on utrace quite prominently. Combined with your reply to one of my questions: > Mark> So you are saying that, at least in principle, it should be possible > Mark> to use the SystemTap toolchain on any ELF-based system to do > Mark> user-space tracing without needing any kernel support? That'd be cool. > Nope, just the static markers coming from . The rest of > SystemTap is Linux-specific, dynamically creating and loading kernel > modules. This confused me enough to think that kernel support was necessary for GDB's usage of the probes as well. > To sum up again, the code in gdb relates to static probe points. > > From the user's point of view, a probe is a spot in the code with a name > and arguments. > > From the implementation point of view, a probe is an entry in an ELF > section, designed in a way to minimize overhead, plus a no-op in the > code. > > GDB reads this new section and uses it to find the probe points, and to > decode the probe arguments. There is zero dependency on System Tap, or > the kernel, or utrace, or anything else. It is purely reading an ELF > section. > > The probe implementation is a header file. Currently this is maintained > in System Tap. However, even this is relatively independent; it depends > on a GCC extension, but this is part of upstream GCC. I would not be > surprised if this code worked on any GCC/ELF system. Thanks for explaining this again. This makes it crystal clear. > Mark> Having the basic SystemTap support in GDB is fine. But depending on > Mark> it to fix issues with core GDB functionality like the ability to debug > Mark> shared libraries is a different matter. It means that people using > Mark> RedHat Linux, almost certainly including any RedHat engineers > Mark> contributing here will no longer test the codepaths that don't rely on > Mark> SystemTap. And people on other Linux variants will never test the > Mark> codepaths that rely on SystemTap. That'll inevitably lead to more > Mark> breakage. > > This is already the situation for compilers and kernels, which in > practice touch much more code in gdb. Yes, but reduction of the number of code paths is still a worthy goal. Anyway, with my misunderstandings about SystemTap cleared up, my reservations about using probes to handle runt-time linker events are gone. I still do think that having those probes in the official glibc tree should be a prerequisite for ading this code to glibc. These probes effectively become part of the libc ABI[1]. We need some sort of commitment from the glibc developers to not break that ABI. And in my view the only way to achieve this is to have those probes upstream. [1] This contradicts what Roland McGrath wrote on the libc-lpha mailing list http://sourceware.org/ml/libc-alpha/2011-03/msg00001.html