From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30012 invoked by alias); 4 Dec 2004 00:38:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28778 invoked from network); 4 Dec 2004 00:38:22 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 4 Dec 2004 00:38:22 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id 1D7456BDF1; Fri, 3 Dec 2004 16:38:20 -0800 (PST) Date: Sat, 04 Dec 2004 00:38:00 -0000 From: Randolph Chung To: John David Anglin Cc: gdb@sources.redhat.com Subject: Re: pc_requires_run_before_use Message-ID: <20041204003819.GM6359@tausq.org> Reply-To: Randolph Chung References: <20041123212126.GR9148@tausq.org> <200411240344.iAO3iGm7008085@hiauly1.hia.nrc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411240344.iAO3iGm7008085@hiauly1.hia.nrc.ca> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00022.txt.bz2 In reference to a message from John David Anglin, dated Nov 23: > > Does anybody understand what this comment means or what this code is > > supposed to do? > > > > hppa_pc_requires_run_before_use() in hppa-tdep.a says: hrm, i found a testcase for this (gdb.base/so-indr-cl). It's hpux-specific. if we create one shared object that exports a function, and then use that function from the main program via an indirect reference, then we trip the check. there's a bit more explanation in the testcase: # This program implicitly loads SOM shared libraries. We wish to test # whether a user can set breakpoints in a shlib before running the # program, where the program doesn't directly call the shlib, but # indirectly does via passing its address to another function. # # ??rehrauer: Currently, this doesn't work, but we do catch the case # and explicitly disallow it. The reason it fails appears to be that # # [1] gdb consults only the linker symbol table in this scenario, and # [2] For a shlib function that is only indirectly called from the # main a.out, there is in the linker symbol table a stub whose # address is negative. Possibly this is to be interpreted as # an index into the DLT?? interestingly, this only triggers when calling a function in a user-defined shared object. in my original test program which calls a function in libc.sl, the problem doesn't occur. i don't know why yet.... i wish there were a "readelf" equivalent for SOM... :) using the same testcase on linux, the reference to the shared object function is not picked up by gdb for the main program before the app is started, so the problem doesn't exist. i guess this may be a problem with the SOM reader where it records a symbol for the unresolved reference to a shlib function.... randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/