From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72365 invoked by alias); 1 Jul 2017 14:35:28 -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 72346 invoked by uid 89); 1 Jul 2017 14:35:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:2479, unaware X-Spam-User: qpsmtpd, 2 recipients X-HELO: homiemail-a119.g.dreamhost.com Received: from sub5.mail.dreamhost.com (HELO homiemail-a119.g.dreamhost.com) (208.113.200.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Jul 2017 14:35:26 +0000 Received: from homiemail-a119.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a119.g.dreamhost.com (Postfix) with ESMTP id 4385860001202; Sat, 1 Jul 2017 07:35:25 -0700 (PDT) Received: from linaro-laptop.intra.reserved-bit.com (unknown [123.252.202.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by homiemail-a119.g.dreamhost.com (Postfix) with ESMTPSA id 1219360001201; Sat, 1 Jul 2017 07:35:21 -0700 (PDT) Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Zack Weinberg , Pedro Alves Cc: Phil Muldoon , GNU C Library , gdb@sourceware.org, Joseph Myers , Florian Weimer , Tom Tromey 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> From: Siddhesh Poyarekar Message-ID: Date: Sat, 01 Jul 2017 14:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-07/txt/msg00001.txt.bz2 On Friday 30 June 2017 10:57 PM, Zack Weinberg wrote: > The _primary_ goal of the glibc patches is to trigger a pretty-printer > when someone does >=20 > (gdb) p errno >=20 > with no further adornment. Since pretty-printers are keyed by type > (and since people do store errno codes in other places than errno), > this involves a type 'error_t' (and its implementation-namespace alias > '__error_t'), but if we can't get 'p errno' to work, we're probably > not going to bother. >=20 > In all currently-supported configurations, this is glibc's definition of = errno: >=20 > extern int *__errno_location (void) __THROW __attribute__ ((__const__)); > #define errno (*__errno_location ()) >=20 > (__THROW is a macro expanding to 'throw ()' when compiling C++.) >=20 > The patches change that to >=20 > extern __error_t *__errno_location (void) __THROW __attribute__ ((__const= __)); >=20 > which should be sufficient to get the pretty-printing happening. But > obviously that's only going to work if GDB actually knows that the > return type of __errno_location is __error_t*, and it doesn't seem to, > *even when debug information for the definition is available*: >=20 > $ gdb /lib/x86_64-linux-gnu/libc.so.6 > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git > ... >=20 > Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols > from /usr/lib/debug/.build-id/cc/80584889db7a969292959a46c718a2b1500702.d= ebug...done. > done. > (gdb) ptype __errno_location > type =3D int () > (gdb) p __errno_location > $1 =3D {} 0x20590 <__GI___errno_location> >=20 > ... a suspicion occurs... >=20 > (gdb) ptype __GI___errno_location > type =3D int *(void) > (gdb) p __GI___errno_location > $2 =3D {int *(void)} 0x20590 <__GI___errno_location> >=20 > ... 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. >=20 > Still, It Would Be Nice=E2=84=A2 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. The __GI_* alias is an internal alias of __errno_location and I've seen this before with other symbols, where a function address resolves to the internal alias instead of the public one in gdb as well as other places like objdump. It might make sense to turn this around, but I suspect there may be a reason for it that I am unaware of. Siddhesh