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

[Tom Tromey <tromey at redhat 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