From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6293 invoked by alias); 25 Mar 2013 19:48:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6264 invoked by uid 89); 25 Mar 2013 19:48:12 -0000 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 19:48:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D35392EA1F; Mon, 25 Mar 2013 15:48:10 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CPlZz+7CkZaw; Mon, 25 Mar 2013 15:48:10 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9E1392E87A; Mon, 25 Mar 2013 15:48:10 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id AEE33C08C3; Mon, 25 Mar 2013 12:48:08 -0700 (PDT) Date: Tue, 26 Mar 2013 03:12:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: FYI/prototype: re-implement relocs on ppc-aix Message-ID: <20130325194808.GL5447@adacore.com> References: <20130321222151.GH5447@adacore.com> <87d2urw7x2.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d2urw7x2.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-03/txt/msg00952.txt.bz2 Hi Tom, Thanks for the feedback, and suggestions. Here is where I think we should stand: I will work on the few minor things I mentioned in my first email, such as separating the tdep part from the nat part. And I will also clean the patch up to bring it to formal submission. I think that the improvements as is are already significant enough that we can ignore the solib-name-and-related issues for the first patch, and work on that separately. Just a few answers to your comments... > Joel> - One important bit is something I alluded to above: a solib > Joel> name is now no longer sufficient to identify it; we need > Joel> the filename, which is usually an archive, and a member > Joel> name (which may be NULL). > > Joel> Some of the options I have considered: > [...] > > It seems to me that the "gold-plated" method would be to change the code > everywhere not to assume a "file name", but instead make a new "solib > name" object that has virtual methods for its operations, and let AIX > supply a subclass of this. [...] > This is a lot more typing, especially if you went the full route and > pushed it into objfiles as well, but I think it would avoid many issues > as well. I see the beauty of it, but at the same time, this is introducing a second level of indirection; is it going to make things better than extending the current target_so_ops by adding handling of member objects? To me, it seems a little overkill, but I do not mind going that direction. (separate patch, probably not before the fall, unfortunately). > One issue with the objfile name is that this impacts auto-loading of > Python. Ah yes, that's true. I don't use Python on this platform; that's why I did not think of this. If we really want to do well, it does seem like we will probably need to push this issue all the way down to objfiles :-(. All of a sudden, I find myself wishing we had opaque types... > Joel> - xcoff_symfile_offsets was greatly simplified, and in fact could be > Joel> entirely replaced by default_symfile_offsets, if it wasn't for > Joel> some code which defaults some section indices in the objfile > Joel> to zero even when the section actually does not exist. I could > Joel> probably work with that because this seems to only affect > Joel> the rodata sect index in practice, and that section does not > Joel> exist on AIX (yet). But I think that's taking a chance. > Joel> The code that does that was added a very long time ago, and > Joel> was probably meant for ELF. For now, I've added code in > Joel> xcoff_symfile_offsets to just call default_symfile_offsets > Joel> followed by the undoing of the sect index zero'ing. Fine > Joel> for now, but something we might want to look at eventually? > > Yeah, this code seems kind of bogus to me. > I think you could refactor default_symfile_offsets so that it calls a > helper function, also called by xcoff_symfile_offsets, and which doesn't > do this setting. I think I have an idea of what you mean, but I don't think I quite see what you mean in practice... Not a big problem, and easy to fix later on. > Joel> +static struct obj_section * > Joel> +data_obj_section_from_objfile (struct objfile *objfile) > Joel> +{ > Joel> + struct obj_section *osect; > Joel> + > Joel> + ALL_OBJFILE_OSECTIONS (objfile, osect) > Joel> + if (strcmp (bfd_section_name (objfile->obfd, osect->the_bfd_section), > Joel> + ".data") == 0) > Joel> + return osect; > > Can this not look at objfile->data_sect_index? Not if I am understanding it right. objfile->sect_index_data is an index in the objfile->section_offsets array. I couldn't convince myself from the current documentation that those indices applied to both objfile->section_offsets and objfile->sections. It would be ideal if I could! > I think my obj_section removal series touches many of these same > spots. It shouldn't cause any big problems, the changes seem to be in > the same direction, just some minor conflicts. > > I was planning to check that series in next week. You'll likely go ahead before I do, thanks for the heads up. -- Joel