From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2595 invoked by alias); 29 Oct 2003 04:21:44 -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 2249 invoked from network); 29 Oct 2003 04:21:18 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Oct 2003 04:21:18 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9T4LHM05542 for ; Tue, 28 Oct 2003 23:21:17 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9T4LH608469 for ; Tue, 28 Oct 2003 23:21:17 -0500 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9T4LGju002152; Tue, 28 Oct 2003 23:21:17 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9T4LBK04800; Tue, 28 Oct 2003 21:21:11 -0700 Date: Wed, 29 Oct 2003 04:21:00 -0000 From: Kevin Buettner Message-Id: <1031029042111.ZM4799@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfa:solib] Handle start-address descriptors" (Oct 27, 6:49pm) References: <3F9D67D7.2090003@redhat.com> <1031028215515.ZM3717@localhost.localdomain> <3F9DAF09.6010003@redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [rfa:solib] Handle start-address descriptors Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00831.txt.bz2 On Oct 27, 6:49pm, Andrew Cagney wrote: > >> +#include "bfd-target.h" > >> +#include "exec.h" > > > > I'm surprised that you needed to include exec.h. solib-svr4.c already > > includes target.h and I would've thought this to be sufficient. If > > exec.h isn't needed, please take it out. (Don't forget to fix Makefile.in.) > > They are both needed. Okay, I've looked over your patch again and I see why now -- the address of exec_ops is being passed to exec_entry_point(). (You could have mentioned this instead of just saying "They are both needed.") > > Could you add a comment here telling why > > gdbarch_convert_from_func_ptr_addr() is needed. Maybe something like > > this? > > I'll add your comment. Thanks. > > 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.) Kevin