From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28057 invoked by alias); 7 May 2012 21:32:07 -0000 Received: (qmail 28045 invoked by uid 22791); 7 May 2012 21:32:06 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_GJ,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; Mon, 07 May 2012 21:31:52 +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 q47LVl9t012158; Mon, 7 May 2012 23:31:47 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q47LVjTN014466; Mon, 7 May 2012 23:31:45 +0200 (CEST) Date: Mon, 07 May 2012 21:32:00 -0000 Message-Id: <201205072131.q47LVjTN014466@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: tromey@redhat.com CC: jan.kratochvil@redhat.com, gdb-patches@sourceware.org, gbenson@redhat.com In-reply-to: <87r4uvwxcg.fsf@fleche.redhat.com> (message from Tom Tromey on Mon, 07 May 2012 14:27:27 -0600) Subject: Re: [RFA] Improved linker-debugger interface References: <20120504152129.GA7418@redhat.com> <20120507165648.GA22472@host2.jankratochvil.net> <87r4uvwxcg.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/msg00202.txt.bz2 > From: Tom Tromey > 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.