From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43672 invoked by alias); 30 Jun 2017 18:11:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 43652 invoked by uid 89); 30 Jun 2017 18:11:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Jun 2017 18:11:55 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 45C6A5A60; Fri, 30 Jun 2017 18:11:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 45C6A5A60 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 45C6A5A60 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3F435D6A4; Fri, 30 Jun 2017 18:11:45 +0000 (UTC) Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Zack Weinberg References: <20170622224456.1358-1-zackw@panix.com> <3a7946e9-d178-f878-9774-64ff44bcf5df@redhat.com> <9490d183-a57b-b336-3131-6580e4773818@redhat.com> <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> Cc: Phil Muldoon , GNU C Library , gdb@sourceware.org, Joseph Myers , Florian Weimer , Tom Tromey , Siddhesh Poyarekar From: Pedro Alves Message-ID: <1d38297f-f430-ca73-6d3f-a67144d08eea@redhat.com> Date: Fri, 30 Jun 2017 18:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-06/txt/msg00049.txt.bz2 On 06/30/2017 06:27 PM, Zack Weinberg wrote: > Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols > from /usr/lib/debug/.build-id/cc/80584889db7a969292959a46c718a2b1500702.debug...done. > done. > (gdb) ptype __errno_location > type = int () > (gdb) p __errno_location > $1 = {} 0x20590 <__GI___errno_location> > > ... a suspicion occurs... > > (gdb) ptype __GI___errno_location > type = int *(void) > (gdb) p __GI___errno_location > $2 = {int *(void)} 0x20590 <__GI___errno_location> > > ... so I guess this is a problem with the __GI_ indirection, which > *may* be a thing we can resolve on our end. I don't fully understand > that stuff. OK, thanks, that's clear. I don't know much about __GI_ indirection either. Redefining errno to call the __GI_ version would probably be too easy. :-) > Still, It Would Be Nice™ if you _didn't_ have to have the debug > symbols for libc.so installed for this to work. Probably a lot of > people think you only need those if you are debugging libc itself. I guess that that could also be seen as a packaging issue. May be it'd be possible to (always) have some kind of minimal debug info available for libc, with only the definitions of public API functions, describing their prototypes, but not their internals? See: https://fedoraproject.org/wiki/Features/MiniDebugInfo > >> The next problem is that without debug info for __errno_location, >> gdb has no clue of its prototype, only that its a function, and so >> it assumes that it has type "int()", i.e., that it returns int, >> while in reality it returns int * / __error_t *. (Falling back >> to assuming "int" is IMO not the best idea, but I don't know >> the history behind it.) > > Probably because that's the pre-C89 legacy default function signature? Yes, most likely. >> One dirty way around it would be for the printer to >> re-define the errno macro (using to cast __errno_location to >> the correct type before calling it, I guess: >> >> (gdb) macro define errno *(*(__error_t *(*) (void)) __errno_location) () >> >> That's make "errno" available when you compile with levels >> lower than -g3, too. > > Hmm. How would one do that from inside Python? There's no direct Python API, I believe. You'd just call the CLI command directly, with gdb.execute. xmethods sounds like something that maybe might be useful here: https://sourceware.org/gdb/onlinedocs/gdb/Xmethods-In-Python.html though from the docs it sounds like you can only replace class methods, not free functions, currently. Not sure, have never written any. Thanks, Pedro Alves