Re: [RFA] MIPS_TEXT symbols should be associated to .text section?

[Joel Brobecker <brobecker@gnat.com>]

Thiemo,

Thanks for the prompt reply. And thanks also to Mark for the feedback.
This is very helpful.

> > > +    case SHN_MIPS_TEXT:
> > > +      { 
> > > +        asection *section = bfd_get_section_by_name (abfd, ".text");
> > > +        if (section != NULL)
> > > +          {
> > > +            asym->section = section;
> > > +            /* MIPS_TEXT is a bit special, the address is not an offset
> > > +               to the base of the .text section.  So substract the section
> > > +               base address to make it an offset.  */
> > > +	    asym->value -= section->vma;
> > > +          }
> > > +        break;
> > > +      }
> > > +    
> > >  #if 0 /* for SGI_COMPAT */
> > >      case SHN_MIPS_TEXT:
> > >        asym->section = mips_elf_text_section_ptr;
> 
> The last three lines in this patch suggest AFAICS to use
> mips_elf_text_section_ptr instead of bfd_get_section_by_name,

I think the commented out code is out of date, mips_elf_text_section_ptr
doesn't exist (anymore?). That's why I had to find it by name.  I should
really delete this code, I will include that in my next patch.

> and to make the test conditional on SGI_COMPAT.

I would have agreed to this, but Mark reported that he has the same
problem on NetBSD/mips, so I guess the SGI_COMPAT is too narrow.
What I can do is conditionalize this code on SHN_MIPS_TEXT itself?
Would that make sense? (the thing is: we already SHN_MIPS_COMMON,
SHN_MIPS_ACOMMON, etc, so do we really need to put any
conditionalization?)

> The SHN_MIPS_DATA
> below should probably get handled similiarily.

I agree. The reason why I didn't include MIPS_DATA to the patch
is that I didn't find any example where I saw an object being
in that special section. So I didn't want to change anything
in case it would make it worse. If you think it should be included,
I'll gladly do so (and contact Dave Anderson of SGI to confirm the
meaning of this special st_shndx).

Let me know.

-- 
Joel