From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26681 invoked by alias); 4 Dec 2004 01:01:31 -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 26638 invoked from network); 4 Dec 2004 01:01:21 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org with SMTP; 4 Dec 2004 01:01:21 -0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id iB411Kko013391; Fri, 3 Dec 2004 20:01:20 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id iB411Jnl013389; Fri, 3 Dec 2004 20:01:19 -0500 (EST) Message-Id: <200412040101.iB411Jnl013389@hiauly1.hia.nrc.ca> Subject: Re: pc_requires_run_before_use To: randolph@tausq.org Date: Sat, 04 Dec 2004 01:01:00 -0000 From: "John David Anglin" Cc: gdb@sources.redhat.com In-Reply-To: <20041204003819.GM6359@tausq.org> from "Randolph Chung" at Dec 3, 2004 07:38:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00023.txt.bz2 > # ??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... :) Have you tried odump? There is a manpage for it on uly3. > 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.... I haven't looked into the mechanics of this as I did for linux. There is info on binding in the ld and dld.sl manpages. There is a millicode routine $$sh_func_adrs that performs function pointer canonicalization. Possibly, understanding the deferred binding mechanism may allow you to detect unresolved references to shlib functions. This is obviously a pain for the user who wants to place a break on such a function. I usely use static linkage or immediate binding when I encounter problems such as this. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)