From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22237 invoked by alias); 30 Jun 2017 16:38:15 -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 20487 invoked by uid 89); 30 Jun 2017 16:38:14 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:65e5, HCc:U*gdb 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 16:38:12 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C1A08008D; Fri, 30 Jun 2017 16:38:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7C1A08008D Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7C1A08008D 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 55FC85D9C4; Fri, 30 Jun 2017 16:37:50 +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> Cc: Phil Muldoon , GNU C Library , gdb@sourceware.org, Joseph Myers , Florian Weimer , tom@tromey.com, Siddhesh Poyarekar From: Pedro Alves Message-ID: <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> Date: Fri, 30 Jun 2017 16:38: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: 7bit X-SW-Source: 2017-06/txt/msg00046.txt.bz2 On 06/30/2017 01:28 AM, Zack Weinberg wrote: > On Thu, Jun 29, 2017 at 1:28 PM, Pedro Alves wrote: >> With this code: >> >> typedef int zzz; >> zzz z; >> >> gdb: >> >> (gdb) whatis z >> type = zzz >> (gdb) whatis (zzz)0 >> type = zzz >> (gdb) whatis zzz >> type = int > I've now sent the patch to gdb-patches: https://sourceware.org/ml/gdb-patches/2017-06/msg00827.html Could one of you check whether the type printer kicks in with that, in the problematic cast case? Phil, might it be a good idea to convert what you were using to a real gdb testsuite test? > 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? -- it does work correctly if a function > *definition* is visible. But we need it to work given only the above, > possibly with no debug symbols in the shared library defining > "errloc". Won't __errno_location be always present in the dynamic symbol table? If you strip everything from libc.so.6 / libpthread.so.0 including dynamic symbols, leaving gdb with no clue about "__errno_location", let alone its address, there's no way that gdb can call it. (Unless you call it by address manually.) 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.) I.e., with your example .o + a separate .o file defining errloc (with no debug info), we now get: (gdb) ptype errloc type = int () and then calling "p *errloc()" (the equivalent of '#define errno (*__errno_location ())' silently subtly does the wrong thing. 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. Fedora gdb has a morally equivalent hack in the source code directly. Ideally, we'd find a clean way to make this all Just Work. Thanks, Pedro Alves