From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25229 invoked by alias); 25 Feb 2013 18:09:24 -0000 Received: (qmail 25216 invoked by uid 22791); 25 Feb 2013 18:09:22 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-ve0-f177.google.com (HELO mail-ve0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Feb 2013 18:09:15 +0000 Received: by mail-ve0-f177.google.com with SMTP id m1so2437655ves.36 for ; Mon, 25 Feb 2013 10:09:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ygYSK57NEUYg3g73ZDjUqIxvsC4YoDQWhrOz9W8mPh0=; b=MqnHhdxZGn72vdhis5MS2g75k7i5ZkKMeeIT2UK37Y65v1ZLwvuFkWwnAXQmRwqGcv pWR4K+bPdk8cOzM8aqq29Z6OghCxKTrhjXQa3ZQDOZXaGI7rATdLhBVDl6LegeCiA9Ft OxFBFkfqcW5zWmO1CAeyuay5gglrFOFFU4HD4GkdhCXp9x8A8FNAUPIsNqeujOokHPT6 E7422CDCVVGluarML8dInE3wED3Ll81T+ced3y1QadvW07d8sxTMTjYTwx5QHq6P8T93 jVhDYlAig2mqinWwx1RX0VANB1AxrXYvICMw0buDcT6JXUSk3sa6In0QpV0hB0fcY9EI UdZg== MIME-Version: 1.0 X-Received: by 10.58.45.71 with SMTP id k7mr2441184vem.0.1361815754323; Mon, 25 Feb 2013 10:09:14 -0800 (PST) Received: by 10.220.200.137 with HTTP; Mon, 25 Feb 2013 10:09:14 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 18:09:00 -0000 Message-ID: Subject: Re: Visibility of ELF symbols not taken into account by certain GDB commands? From: Doug Evans To: Alfonso Acosta Cc: gdb Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmYaNPJauH/VG8FtNpkOlf89EgqJCcojoPX1uESeEScA2slbL+XeXGQGbvxYOTg/1KcmkYLVUurjeV+pfBKG5mCnO+X57Pl8wyqIshEdWCVG0ulGXEanvaL+4WJ/aOaNma08oKNXGaDk1hcd9PznCdvKm1Q+OB4+oes6e3Da0GwnvPYSErDxY7SDTeosF1rSvpKbrY+ X-IsSubscribed: yes 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 X-SW-Source: 2013-02/txt/msg00090.txt.bz2 On Fri, Feb 22, 2013 at 7:09 AM, Alfonso Acosta wrote: > Hi, > > I have observed that certain commands, ("print" and "info symbol" at > least) pick only one symbol in case of multible definitions (e.g. > malloc is defined in ls.so and libc.so, but only one of them is > picked). > > During that selection, visibility is not taken into account (e.g. the > ld.so malloc symbol is used although the globally visible one, from > the dynamic loaders point of view, is the one in libc.so) > > > Should this be considered a bug? > > > At the very least, it seems very counterintuitive to me. I would had > expected either using all occurrences of the symbol or picking the > visible one. > > This issue is well covered by I question I made in Stackoverflow [1]. > Here is an example of what I mean: > > (gdb) info symbol malloc > malloc in section .text of /lib64/ld-linux-x86-64.so.2 > (gdb) p malloc > $1 = {void *(size_t)} 0x7ffff7df0930 > (gdb) info symbol 0x7ffff7df0930 > malloc in section .text of /lib64/ld-linux-x86-64.so.2 > (gdb) b malloc > Breakpoint 2 at 0x7ffff7df0930: malloc. (2 locations) > (gdb) info breakpoints > Num Type Disp Enb Address What > 2 breakpoint keep y > 2.1 y 0x00007ffff7df0930 in malloc at > dl-minimal.c:95 > 2.2 y 0x00007ffff7a9f9d0 in > __GI___libc_malloc at malloc.c:2910 > (gdb) > > > Thanks, > > Alfonso Acosta > > > PS: I am running "GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02". > > [1] http://stackoverflow.com/questions/14867024/duplicated-memory-management-symbols-in-libc-so-and-ld-linux-so/15008471#15008471 Hi. Lots of things to consider here, and I may not cover everything in the first pass. In random order: 1) ELF symbol visibility doesn't really enter the picture. Sometimes you don't want it to. Though I can see a usefulness in having knobs to control this, I'm not aware of any (could just be my bad memory :-)) or any plans to add them. [GDB needs to be file-format agnostic in general, but that doesn't mean it can't provide file-format-specific features if they're useful enough.] 1) The print command takes an expression. While in theory one could have gdb do something like evaluate the expression for all values of a name, I haven't seen any real need for it. What happens, in a nutshell, is gdb looks up the symbol in the current context (whatever that is), and then does a search over all contexts. This involves doing a linear search over the binary and all shared libraries and using the first one found. In this case it's the one in ld.so. That doesn't always find the copy one wants of course, and one TODO is to support more expressiveness in specifying which version of a symbol one wants. Note that one thing you can (or rather should be able to) do today, given that you know the source file, and that the source file names are different, is things like p 'malloc.c'::malloc though I see that's busted. Blech. IWBN to be able to do things like p objfile::file::symbol. RSN. ["objfile" is gdb parlance for the binary or a shared lib] 2) break works differently because it's easier to do, and more useful. E.g., it's useful to set a breakpoint on all copies of static function "foo" (or inlined function "foo"), setting aside shared libraries. 3) "info sym foo" takes an address, and an "address" is really just a single entity. The fact that "info sym malloc" works at all is arguably just a convenience hack for the common case. OTOH, "info addr foo" could print multiple results since in this case "foo" is a symbol which can have multiple instances. That would be a useful extension.