From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7223 invoked by alias); 12 Aug 2010 03:17:51 -0000 Received: (qmail 7214 invoked by uid 22791); 12 Aug 2010 03:17:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Aug 2010 03:17:46 +0000 Received: by wwb34 with SMTP id 34so939549wwb.12 for ; Wed, 11 Aug 2010 20:17:44 -0700 (PDT) Received: by 10.216.44.208 with SMTP id n58mr6094445web.73.1281583064257; Wed, 11 Aug 2010 20:17:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.186.205 with HTTP; Wed, 11 Aug 2010 20:17:24 -0700 (PDT) In-Reply-To: <20100811203057.GA25122@caradoc.them.org> References: <1281513884.1935.7.camel@gumtree> <20100811203057.GA25122@caradoc.them.org> From: Hui Zhu Date: Thu, 12 Aug 2010 03:17:00 -0000 Message-ID: Subject: Re: [RFC] make gdb handle weak function better To: Chris January , Hui Zhu , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2010-08/txt/msg00071.txt.bz2 On Thu, Aug 12, 2010 at 04:31, Daniel Jacobowitz wro= te: > On Wed, Aug 11, 2010 at 09:04:44AM +0100, Chris January wrote: >> I don't think this is right. My understanding is that the linker >> (ld-linux) doesn't keep searching other shared libraries if it finds a >> weak symbol. So the search order is as follows: >> 1. 'strong' calloc in libc.so.6. >> 2. 'weak' calloc in libc.so.6. >> 3. 'strong' calloc in ld-linux.so.2. >> 4. 'weak' calloc in ld-linux.so.2. > > There won't be both a strong and weak symbol in the same library; not > from the point of view of ld.so. =A0There may be in the static symbol > table (.symtab) but only one will end up in .dynsym/.hash/.gnu_hash. > > But the important point is this one: > >> Notice that a 'weak' calloc in libc trumps any definition of calloc in >> ld-linux. > > This is correct. > >> The problem with gdb is that it search the shared libraries in the order >> they were loaded - notice info sharedlibrary gave you ld-linux first >> instead of libc - so gdb incorrectly picks ld-linux's calloc. As a >> general heuristic gdb should instead start looking for symbols in the >> most recently loaded shared library (i.e. objfile) (after the main >> executable) and work backwards. This doesn't necessarily match the >> dynamic linker's behaviour exactly, but it gets pretty close for little >> effort. > > That makes sense, although it may be system-specific. =A0Even better > would be to revisit our support for multiple-location breakpoints. > "break calloc" ought to stop on every instance of calloc. > That will be the best. But looks need a big update. #0 lookup_symbol (name=3D0xbfe59b30 "memset", block=3D0x9ac4138, domain=3DVAR_DOMAIN, is_a_field_of_this=3D0x0) at ../../src/gdb/symtab.c:1091 During symbol reading, DW_AT_name missing from DW_TAG_base_type. During symbol reading, unsupported tag: 'DW_TAG_const_type'. #1 0x0839febf in find_imps (symtab=3D0x0, block=3D0x9ac4138, method=3D0x94aa3ba "memset", syms=3D0x0, nsym=3D0xbfe59c68, ndebug=3D0xbfe59c64) at ../../src/gdb/objc-lang.c:1331 #2 0x082f4592 in decode_objc (argptr=3D0xbfe59f14, funfirstline=3D1, file_symtab=3D0x0, canonical=3D0xbfe59ef4, saved_arg=3D0x94aa3ba "memset") at ../../src/gdb/linespec.c:1145 #3 0x082f3c45 in decode_line_1 (argptr=3D0xbfe59f14, funfirstline=3D1, default_symtab=3D0x9ac4248, default_line=3D24, canonical=3D0xbfe59ef4, not_found_ptr=3D0xbfe59ee0) at ../../src/gdb/linespec.c:777 #4 0x082aa5e5 in parse_breakpoint_sals (address=3D0xbfe59f14, sals=3D0xbfe59ebc, addr_string=3D0xbfe59ef4, not_found_ptr=3D0xbfe59ee0) at ../../src/gdb/breakpoint.c:7250 #5 0x082aa7f0 in do_captured_parse_breakpoint (ui=3D0x95a9398, data=3D0xbfe59e98) at ../../src/gdb/breakpoint.c:7320 #6 0x08312b38 in catch_exception (uiout=3D0x95a9398, func=3D0x82aa7b8 , func_args=3D0xbfe59e98, mask=3D6) at ../../src/gdb/exceptions.c:468 #7 0x082aaea4 in create_breakpoint (gdbarch=3D0x9a814c8, arg=3D0x94aa3ba "memset", cond_string=3D0x0, thread=3D0, parse_condition_and_thread=3D1, tempflag=3D0, type_wanted=3Dbp_breakpoint, ignore_count=3D0, pending_break_support=3DAUTO_BOOLEAN_AUTO, ops=3D0x0, from_tty=3D1, enabled=3D1) at ../../src/gdb/breakpoint.c:7502 #8 0x082ab5aa in break_command_1 (arg=3D0x94aa3ba "memset", flag=3D0, from_tty=3D1) at ../../src/gdb/breakpoint.c:7723 #9 0x082ab745 in break_command (arg=3D0x94aa3ba "memset", from_tty=3D1) at ../../src/gdb/breakpoint.c:7795 Do you have some good idea on it? Thanks, Hui > -- > Daniel Jacobowitz > CodeSourcery >