From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21268 invoked by alias); 8 May 2012 05:45:12 -0000 Received: (qmail 21242 invoked by uid 22791); 8 May 2012 05:45:07 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 May 2012 05:44:45 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q485ijxY029701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 01:44:45 -0400 Received: from psique ([10.3.112.12]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q485idjT022092; Tue, 8 May 2012 01:44:41 -0400 From: Sergio Durigan Junior To: Mark Kettenis Cc: tromey@redhat.com, jan.kratochvil@redhat.com, gdb-patches@sourceware.org, gbenson@redhat.com 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> X-URL: http://www.redhat.com Date: Tue, 08 May 2012 05:45:00 -0000 In-Reply-To: <201205072131.q47LVjTN014466@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Mon, 7 May 2012 23:31:45 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00208.txt.bz2 Hi Mark, On Monday, May 07 2012, Mark Kettenis wrote: > 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! SystemTap is not a Red Hat-specific thing, and the support that I have added on GDB does not rely on utrace at all. It seems we are talking about two different things here (userspace probes vs. kernel probes). GDB currently supports static probes in userspace. Those happen to be implemented by SystemTap using , and (again) does not depend on utrace, but rather on GCC + ELF support (that's why Jan asked me to make the compilation of `stap-probe.c' conditional to the ELF support on the target). FWIW, Debian also ships a version of : http://packages.debian.org/squeeze/all/systemtap-sdt-dev/filelist Some distros do not ship it, but they can perfectly do so if their community wants. And the upstream GCC already have static probes in it, along with many more projects. So in my view, this is not Red Hat specific, nor utrace-dependent. > 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. I hope I made it clear that, as a non-utrace-dependent feature, I think this precondition is not valid anymore. >> 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. The support is present in the GDB tree. -- Sergio