From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101080 invoked by alias); 12 Feb 2019 14:04:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 101065 invoked by uid 89); 12 Feb 2019 14:04:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Feb 2019 14:04:16 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1CE1o23057867 for ; Tue, 12 Feb 2019 09:04:15 -0500 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qkvg201hm-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 12 Feb 2019 09:04:12 -0500 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 12 Feb 2019 14:04:04 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 12 Feb 2019 14:04:02 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x1CE41Oh58523670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 12 Feb 2019 14:04:01 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 84F2111C069; Tue, 12 Feb 2019 14:04:01 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 706A911C058; Tue, 12 Feb 2019 14:04:01 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.213.67]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 12 Feb 2019 14:04:01 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 3F628D802C8; Tue, 12 Feb 2019 15:04:01 +0100 (CET) Subject: Re: [RFAv2 3/3] Make symtab.c better styled. To: palves@redhat.com (Pedro Alves) Date: Tue, 12 Feb 2019 14:04:00 -0000 From: "Ulrich Weigand" Cc: philippe.waroquiers@skynet.be (Philippe Waroquiers), gdb-patches@sourceware.org In-Reply-To: from "Pedro Alves" at Feb 12, 2019 01:26:56 PM MIME-Version: 1.0 x-cbid: 19021214-0008-0000-0000-000002BF8F43 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19021214-0009-0000-0000-0000222BA88B Message-Id: <20190212140401.3F628D802C8@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SW-Source: 2019-02/txt/msg00137.txt.bz2 Pedro Alves wrote: > So even though function descriptors are data symbols, they're > basically treated as text/code symbols. The msymbol_is_function > function returns true for them, and optionally returns the resolved > entry address (which is where we place a breakpoint). > > Since these function descriptor symbols represent functions, even though > they're data symbols in the elf tables, it would seem natural to me to > print them using the function name style. > > What I'm not sure is whether we'll reach print_msymbol_info with > data descriptor symbols when we do "info functions". Seems like > search_symbols won't consider those symbols when looking for > functions for "info functions". So we'd find those symbols only > with "info variables", and then we'd print them as functions? > > I guess it could be argued that we should fix search_symbols > / "info functions" to consider function descriptors, and use > msymbol_is_function in print_msymbol_info to decide whether > to use function style. I'm not 100% sure it needs fixing, and whether > making "info functions" find the descriptors like that is the > desired behavior. > > It wouldn't be fair to impose "info functions" on PPC64 on you, > though. > > So if we don't fix that (and assuming it actually needs fixing, I'm > not sure), then I guess the question is whether we should still > print function descriptor symbols in function style, via > "info variable" or whatever other paths could end up calling > print_msymbol_info in the future. > > I'm not 100% sure what is preferred here. Ulrich, thoughts? In addition to the function descriptor, which is a data symbol, we also get a function symbol for the actual code entry point, prefixed with a dot ('.'). This is synthesized by BFD these days. I've just checked the current behavior on a ppc64 machine, and we do indeed see the (synthetic) dot symbol listed under "info functions" and the function descriptor symbol listed under "info variables". (gdb) info functions [...] Non-debugging symbols: 0x0000000010000514 .main (gdb) info variables [...] Non-debugging symbols: 0x0000000010020088 main On the other hand, "info symbol main" does dereference the function descriptor and returns the code entry point: (gdb) info symbol main .main in section .text of /home/uweigand/a.out This all is maybe not perfect, but seems reasonable enough to me. I'm not sure it's worth spending much effort trying to "fix" anything here. I haven't followed the patch series in detail, do you think it would break anything I've outlined above? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com