From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56617 invoked by alias); 4 Jul 2017 15:54: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 56572 invoked by uid 89); 4 Jul 2017 15:54:39 -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=Hx-languages-length:1398, our 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; Tue, 04 Jul 2017 15:54:37 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D7994E341; Tue, 4 Jul 2017 15:54:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8D7994E341 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8D7994E341 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 293C068862; Tue, 4 Jul 2017 15:54:21 +0000 (UTC) Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Siddhesh Poyarekar , 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 From: Pedro Alves Message-ID: Date: Tue, 04 Jul 2017 15:54: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-07/txt/msg00002.txt.bz2 On 07/01/2017 03:35 PM, Siddhesh Poyarekar wrote: > On Friday 30 June 2017 10:57 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. > > 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. > I look at this a bit today, and sent a gdb patch to handle this better now: https://sourceware.org/ml/gdb-patches/2017-07/msg00018.html I pushed it to the same branch as the other one: users/palves/whatis. Thanks, Pedro Alves