From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10109 invoked by alias); 29 Oct 2003 15:47:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10097 invoked from network); 29 Oct 2003 15:47:37 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 15:47:37 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 255122B89; Tue, 28 Oct 2003 10:46:08 -0500 (EST) Message-ID: <3F9E8F40.10205@gnu.org> Date: Wed, 29 Oct 2003 15:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [rfa:solib] Handle start-address descriptors References: <3F9D67D7.2090003@redhat.com> <1031028215515.ZM3717@localhost.localdomain> <3F9DAF09.6010003@redhat.com> <1031029042111.ZM4799@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00837.txt.bz2 >> > Hmm, a possible problem... What happens when the target uses function >> > descriptors, but not for the exec file's start address? I'm wondering >> > (ugh) if a separate gdbarch method is required for obtaining the start >> > address. > >> >> Fortunatly a previous patch addressed that problem. The convert >> function is only applied to positively identified descriptors. > > > If I'm not mistaken, this problem has been addressed for ppc64 and > ia64, but not in a generic fashion. I'm concerned about some other > ABI (for some other architecture) which has function descriptors, but > has no easy way to discriminate between descriptors and code > addresses. If this ABI specifies that the entry point should refer to > a code address instead of a descriptor, then we need a more > complicated mechanism -- perhaps that separate gdbarch method that I > mentioned earlier. > I suppose we can wait to do something about this problem until it > actually arises. But... since we've identified a potential problem, > we should at least document it in some appropriate location. If > the convert_from_func_ptr_addr() method *must* (due to the way it > is used elsewhere) contain a discrimination mechanism, then this > should be mentioned in the documentation. (BTW, I don't see this > method documented in gdbint.texinfo.) Can I encourage you to write this up and add it to the doco? The method most affects the ia64 and ppc/rs6000 targets that you maintain. There is no value-add in taking it any further though. I'll commit the solib-svr4.c change stuff once I've drained a few other pending patches. Andrew