From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9795 invoked by alias); 30 Jun 2017 17:27:40 -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 9760 invoked by uid 89); 30 Jun 2017 17:27:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*tom, involves, reality X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailbackend.panix.com Received: from mailbackend.panix.com (HELO mailbackend.panix.com) (166.84.1.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Jun 2017 17:27:37 +0000 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by mailbackend.panix.com (Postfix) with ESMTPSA id 36DB410906; Fri, 30 Jun 2017 13:27:34 -0400 (EDT) Received: by mail-io0-f182.google.com with SMTP id h134so27787737iof.2; Fri, 30 Jun 2017 10:27:34 -0700 (PDT) X-Gm-Message-State: AKS2vOyoD1N/MUBhzQhN8/06Qg+DGhj5C1vk2myQLx5tn/NZnJ20VtYi wggjiLUQDXnUwMuXGaKcJjnhIdeRTw== X-Received: by 10.107.205.193 with SMTP id d184mr26856032iog.188.1498843654104; Fri, 30 Jun 2017 10:27:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.202.132 with HTTP; Fri, 30 Jun 2017 10:27:33 -0700 (PDT) In-Reply-To: <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> 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: Zack Weinberg Date: Fri, 30 Jun 2017 17:27:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Pedro Alves Cc: Phil Muldoon , GNU C Library , gdb@sourceware.org, Joseph Myers , Florian Weimer , Tom Tromey , Siddhesh Poyarekar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-06/txt/msg00048.txt.bz2 On Fri, Jun 30, 2017 at 12:37 PM, Pedro Alves wrote: > On 06/30/2017 01:28 AM, Zack Weinberg wrote: >> For the glibc patch to go through, this case also needs to work: >> >> typedef int error_t; >> error_t var; >> extern error_t *errloc(void); >> >> int main(void) >> { >> return *errloc(); >> } >> >> (compiled to .o file) >> >> (gdb) ptype errloc >> No symbol "errloc" in current context. >> >> This might be a problem with inadequate debugging information >> generated by the compiler > > Debug info is generated for function definitions, not declarations. > I.e., that declaration for "errloc" alone produces no debug info > at all. Try 'readelf -dw' on the .o file. > > But why is this a valid scenario? Even if you have no debug info, > GDB should be able to find the function's address in the elf dynamic > symbol table? > > I'm not sure what you mean by "glibc patch to go through". > If you mean acceptance upstream, then I'd consider this a separate > issue, because now you're talking about being able to print the > "errno" variable in the first place, even as a plain int with no > printer? That is related, but orthogonal from the error_t type printer? > Otherwise, can you clarify? The _primary_ goal of the glibc patches is to trigger a pretty-printer when someone does (gdb) p errno 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. In all currently-supported configurations, this is glibc's definition of er= rno: extern int *__errno_location (void) __THROW __attribute__ ((__const__)); #define errno (*__errno_location ()) (__THROW is a macro expanding to 'throw ()' when compiling C++.) The patches change that to extern __error_t *__errno_location (void) __THROW __attribute__ ((__const__= )); 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*: $ gdb /lib/x86_64-linux-gnu/libc.so.6 GNU gdb (Debian 7.12-6) 7.12.0.20161007-git ... Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug/.build-id/cc/80584889db7a969292959a46c718a2b1500702.deb= ug...done. done. (gdb) ptype __errno_location type =3D int () (gdb) p __errno_location $1 =3D {} 0x20590 <__GI___errno_location> ... a suspicion occurs... (gdb) ptype __GI___errno_location type =3D int *(void) (gdb) p __GI___errno_location $2 =3D {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. 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 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? > 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? zw