This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: FYI/prototype: re-implement relocs on ppc-aix
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 22 Mar 2013 13:28:41 -0600
- Subject: Re: FYI/prototype: re-implement relocs on ppc-aix
- References: <20130321222151 dot GH5447 at adacore dot com>
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> 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 "<my_archive->name>(<objfile->name>)";
Joel> otherwise, the usual "<objfile->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