Re: [RFA] fix build failure in solib-som.c

Kevin Buettner
2007-08-07T23:20:01Z

On Tue, 7 Aug 2007 15:43:48 -0700
Joel Brobecker <brobecker@adacore.com> wrote:

> > > I haven't tested this change, but wouldn't the attached patch make sense?
> > > I don't think we need to keep track of which section is the text section
> > > at this place, since this is done differently somewhere else (in the
> > > current_sos method). So I just removed the associated piece of code.
> > >
> > > 2007-08-07 Joel Brobecker <brobecker@adacore.com>
> > >
> > > * solib-som.c (som_relocate_section_addresses): Stop saving
> > > the $CODE$ section in the so_list structure.
> > >
> > > This files compiles fine again after this change is applied.
> > >
> > > Would that be OK to apply?
> >
> > I think it would be better to revise the code to set so->addr_low and
> > so->addr_high to sec->addr and sec->endaddr respectively. You'll also
> > have to move this block of code to the end of the function.
>
> Isn't that already done in som_current_sos, though?

It is, but those addresses won't be relocated. In order to be
consistent with the other ports, I think these values should be
relocated. Note that solib.c's solib_map_sections() sets `addr_low'
and `addr_high' for .text after the relocation has been done. Clearly
this won't work for SOM since the .text section is named differently.
However, given that `addr_low' and `addr_high' are set after the
relocation has been performed (for other ports with a .text), I think
it makes sense to arrange the SOM-specific code as suggested in my
earlier reply. I'm beginning to think too that the assignments to
addr_low and addr_high ought to be removed from som_current_sos().

That said, it's not critical that `addr_low' and `addr_high' be
relocated since they're only used for display purposes in "info
sharedlibrary". If it makes more sense for this port to display
unrelocated values, them I'm happy with your original patch. I'll
leave it to you to decide the best course of action.

Kevin