From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10068 invoked by alias); 9 May 2012 15:57:07 -0000 Received: (qmail 10060 invoked by uid 22791); 9 May 2012 15:57:05 -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,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; Wed, 09 May 2012 15:56:52 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q49Fuq72009816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 May 2012 11:56:52 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q49Fuo3V022205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 May 2012 11:56:51 -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> <8762c6x08n.fsf@fleche.redhat.com> <201205090811.q498BqhT006233@glazunov.sibelius.xs4all.nl> Date: Wed, 09 May 2012 15:57:00 -0000 In-Reply-To: <201205090811.q498BqhT006233@glazunov.sibelius.xs4all.nl> (Mark Kettenis's message of "Wed, 9 May 2012 10:11:52 +0200 (CEST)") Message-ID: <87fwb9tkjh.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/msg00279.txt.bz2 >>>>> "Mark" == Mark Kettenis writes: Mark> Mark> which mentions the dependency on utrace quite prominently. You want http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation Mark> Anyway, with my misunderstandings about SystemTap cleared up, my Mark> reservations about using probes to handle runt-time linker events are Mark> gone. I still do think that having those probes in the official glibc Mark> tree should be a prerequisite for ading this code to glibc. These Mark> probes effectively become part of the libc ABI[1]. We need some sort Mark> of commitment from the glibc developers to not break that ABI. And in Mark> my view the only way to achieve this is to have those probes upstream. FWIW for the longjmp case, where the code is currently in-tree, there really aren't alternative code paths to consider. Due to PC mangling, the existing longjmp code simply doesn't work with any glibc newer than 2006 or so. I've asked the local glibc folks to try again to push the patches. If you take Roland's lack of ABI promise seriously, and combine it with your reasoning above, then we must never use these probes in gdb. But, that is an absurd result, since the probes basically exist for use by gdb. So, something has to give. I think that if gdb were using the probes, we can use this to argue that glibc should only make ABI-compatible changes. The ABI rules for probes are much more relaxed than the rules for normal C constructs, so this is not a problem. There are two choices for ABI compatible changes here; one is to keep existing probe names and arguments, adding any needed new arguments to the end of the list; or simply renaming the probes. Deleting probes is also ok (contrary to the usual glibc ABI rules), because gdb and other users will always be adaptive. In sum, I don't consider this a problem in practice. I'm confident that glibc maintainers will listen to reason. Tom