Re: FYI/prototype: re-implement relocs on ppc-aix

[Joel Brobecker <brobecker@adacore.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