From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26850 invoked by alias); 22 Mar 2013 19:28:57 -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 26833 invoked by uid 89); 22 Mar 2013 19:28:49 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 22 Mar 2013 19:28:46 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2MJShsk002907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Mar 2013 15:28:44 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2MJSf3N024642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 15:28:42 -0400 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: FYI/prototype: re-implement relocs on ppc-aix References: <20130321222151.GH5447@adacore.com> Date: Fri, 22 Mar 2013 20:43:00 -0000 In-Reply-To: <20130321222151.GH5447@adacore.com> (Joel Brobecker's message of "Thu, 21 Mar 2013 15:21:51 -0700") Message-ID: <87d2urw7x2.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-03/txt/msg00863.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> This patch is a prototype towards converting all the ad hoc code Joel> and various deprecated features used to implement relocations to Joel> using a target_so_ops vector instead. One of the nice side-effects Joel> is that we are able to get rid of nm-rs6000.h entirely. Very nice. 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. struct solib_name_base { const struct solib_name_vtable *vtable; }; struct solib_name_simple { struct solib_name_base base; char *filename; }; struct solib_name_aix { struct solib_name_base base; char *filename; char *member_name; }; Then maybe with methods like: struct solib_name_vtable { /* Destructor. */ void (*dtor) (struct solib_name_base *); /* Return a malloc'd "print name". */ char *(*print_name) (struct solib_name_base *); /* Use this instead of target_so_ops -> bfd_open */ bfd *(*bfd_open) (struct solib_name_base *); ... whatever else you need ... }; 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. Assuming I didn't miss or misunderstand something. I'm having trouble telling if this would work or not. Joel> - Issue when printing the objfile name: This one is going Joel> to be messy, I think. I was thinking of defining the Joel> concept of an objfile's "print" name, which could work Joel> as follow: If the objfile's bfd has a my_archive, then Joel> it would be "name>(name>)"; Joel> otherwise, the usual "name>". I don't think Joel> we really need to address that issue, especially not Joel> right now. One issue with the objfile name is that this impacts auto-loading of Python. I think we already need an objfile bit saying "this is a regular file" versus "this is some non-file entity". The above wouldn't be an issue if we had this. 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. IIRC the defaulting was added to cope with a .so that had no .text section, or something like that. Previously you could get errors from gdb in that case. I.e., that might have actually been just papering over a bug elsewhere. Joel> +/* FIXME: Define in a more general location? */ Joel> + 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? Joel> @@ -2342,12 +2348,10 @@ scan_xcoff_symtab (struct objfile *objfile) Joel> /* Data variables are recorded in the minimal symbol Joel> table, except for section symbols. */ Joel> if (*namestring != '.') Joel> - prim_record_minimal_symbol_and_info Joel> + record_minimal_symbol Joel> (namestring, symbol.n_value, Joel> sclass == C_HIDEXT ? mst_file_data : mst_data, Joel> - secnum_to_section (symbol.n_scnum, objfile), Joel> - secnum_to_bfd_section (symbol.n_scnum, objfile), Joel> - objfile); Joel> + symbol.n_scnum, objfile); Joel> break; 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. Tom