From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22726 invoked by alias); 8 May 2012 13:37:32 -0000 Received: (qmail 22545 invoked by uid 22791); 8 May 2012 13:37:30 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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 13:37:14 +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 q48DbE6h000833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 09:37:14 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q48DbCMO014063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 May 2012 09:37:13 -0400 From: Tom Tromey To: Mark Kettenis Cc: 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> Date: Tue, 08 May 2012 13:37: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: <8762c6x08n.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00221.txt.bz2 >>>>> "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. 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. 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. Tom