From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9699 invoked by alias); 16 Oct 2007 02:39:36 -0000 Received: (qmail 9688 invoked by uid 22791); 16 Oct 2007 02:39:35 -0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_FAIL,SUBJ_HAS_SPACES X-Spam-Check-By: sourceware.org Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (204.127.200.83) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Oct 2007 02:39:33 +0000 Received: from gateway.sf.frob.com (c-67-160-211-197.hsd1.ca.comcast.net[67.160.211.197]) by comcast.net (sccrmhc13) with ESMTP id <2007101602393001300pfl7ue>; Tue, 16 Oct 2007 02:39:30 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 7D1F0357B; Mon, 15 Oct 2007 19:39:19 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 95A054D0389; Mon, 15 Oct 2007 19:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Frysk Hackers Subject: Re: dl symbol search path; Was: Corefile -arch 32 test failures with breakpoint and stacktrace tests In-Reply-To: Andrew Cagney's message of Tuesday, 9 October 2007 13:28:52 -0400 <470BBA54.9060701@redhat.com> References: <47074377.5040602@redhat.com> <1191840378.3859.20.camel@dijkstra.wildebeest.org> <470BB52E.9010606@redhat.com> <470BBA54.9060701@redhat.com> X-Zippy-Says: Why am I in this ROOM in DOWNTOWN PHILADELPHIA? Message-Id: <20071016023848.95A054D0389@magilla.localdomain> Date: Tue, 16 Oct 2007 02:39:00 -0000 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00055.txt.bz2 Sorry, there is indeed no handy function to help you with this. I'm sure we will have one eventually. But doing it really right does involve really severe amounts of hair, which are all in the 90% to get the last 10%. The best we can try to do for now is to stub it out with the trivial naive search, but inside an interface that asks the question the right way. The goal is to resolve the ELF symbol reference that would have been done by referring to a particular name in a particular source context. When reduced to ELF terms, these components describe a reference: 1. symbol name 2. symbol version binding 3. Dwfl_Module making the reference 4. purpose of the reference To take each of these in detail: 1. This is the name string used in the ELF symbol table, obviously. Resolving what a name used in a particular context in the source would actually yield as an ELF name is in fact quite difficult for all the complex cases, though 90% of cases are trivial. I won't go into all the gory details of those problems now. It suffices to observe the context necessary to do the best possible job: DWARF scope DIE of the desired context, if available (either CU or inner); language mode if not implicit from CU; module the reference is being made from. 2. The symbol version is approximately a second and third part to the symbol name. It is usually determined (bound) only at link time, not by the compiler nor in assembly source code; DWARF is never much help figuring it out. It's only an issue when there are two definitions with the same name and different symbol versions. This is likely for e.g. printf and some libstdc++ name-mangled symbols, but not very common in Joe Blow's DSO. Given a module to consider as the context making the reference, when there is an existing external reference in that module to a given symbol name, that pretty much makes it easy. (It's possible to refer to two different symbols with the same name and different versions inside one module. But it's so inconvenient that even DSOs like libc that define multiple symbols by the same name don't use the versioned mechanism to refer to their own symbols between CUs, they just use private aliases with different names.) If there was no reference to this symbol linked into the context module, then you can't in all cases get an unambiguously right answer. But there is no information helpful to that guessing more granular than just the module as context. 3. Every reference is in the context of some module or other, even if not in the context of a known CU/scope. If the context of the user request seems to be "global, I don't care exactly what I mean", then either this means the main program module, or it means accepting the result is a map of different results given different contexts in cases of ambiguity. 4. The purposes for reference that we must distinguish are: a. like a PLT reloc, a jump target b. like a COPY reloc, an initializer value c. like all others, an object address For "func(args)", and probably for a breakpoint on func, it's (a). For "&func", it's (c). In module A using PIC that calls func in module B, (a) means func's real definition in B; (c) means func's PLT symbol in A. For a non-PIC object (i.e. the main program) that does "extern int foo;" and links to a DSO that does "int foo = 1;", then (b) is foo's symbol in the main program; (c) is foo's definition in the DSO. When the reference is to "the variable foo", to see its live value in the program, change it, place a watchpoint, it's (c). When the reference is to print the static initializer value, offline or before the program has finished dynamic loading at startup/dlopen, then it's (b). The (a) vs (c) and (b) vs (c) distinctions often apply to a module's own references to its own symbols, though I used less confusing examples above. So purpose is relevant to every lookup. At high level, we can describe the purpose distinctions as "for actual code address", "for static initializer data", and "for object address". So, gleaned from that, the lookup function should have at hand: * symbol name * DWARF scope DIE of the desired context, if available * language mode, if no scope/CU context * referring module, if available * purpose of reference Furthermore, it should be able to return ambiguous results. That is, the result of the lookup is either "this one is it", or a list of candidates each annotated with "this would be it if you were to give foobar as the referring module" and/or "this would be it if this reference by module foobar were resolved to symbol version V in module M". It's fine for now if the only plan for the ambiguous cases is an exception "couldn't figure it out" or even "blindly pick the first one". But one should contemplate how the description of the ambiguity and the options for resolving it might percolate up to the user. Thanks, Roland