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: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 25 Mar 2013 12:48:08 -0700
- Subject: Re: FYI/prototype: re-implement relocs on ppc-aix
- References: <20130321222151 dot GH5447 at adacore dot com> <87d2urw7x2 dot fsf at fleche dot redhat dot com>
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