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

[Joel Brobecker <brobecker@gnat.com>]

Hello BFD maintainers,

Ping? This patch is only 8 days old, and I wouldn't send a reminder
just a week after sending it, but GDB is completely broken without
this patch (ie "break main; run" doesn't work)... Would somebody mind
having a look at it and tell me if it is good or not?

Thank you,
-- 
Joel

On Wed, Jul 21, 2004 at 01:46:04PM -0700, Joel Brobecker wrote:
> Hello,
> 
> I was looking at a fairly high number of regressions in the GDB
> testsuite on mips-irix, and one of them was caused by the fact
> that we searched a symbol by its address and that we match the
> possible candidates against the expected section.
> 
> For instance, consider the following symbol "main" from my executable.
> nm on this symbol says:
> 
>     [76]    | 268441176|     252|FUNC |GLOB |DEFAULT  |MIPS_TEXT|main
> 
> GDB is searching the symbol table for a symbol stored at 0x10001658
> (268441176 = 0x10001658). The first thing it does is going through
> all the sections of the executable, and determine that there is only
> one section that contains this address: .text. So it figures that
> if a symbol matches this address, it will belong to that section.
> 
> After that, it scans all symbols by address, and only find one symbol,
> the symbol above. But unfortunately, because the st_shndx is a bit
> special (SHN_MIPS_TEXT = 0xff01), it doesn't point to the .text
> section directly. So when bfd was used to read the symbol table,
> it defaulted the section of this symbol to an imaginary *ABS* section.
> And because of that, GDB discards my symbol because the section
> does not match.
> 
> Objdump shows the same behavior:
> 
>         % objdump -T annota1 | grep main
>         10001658 g    DF *ABS*        000000fc main
> 
> Not knowing IRIX enough, I am not 110% sure that symbol main is indeed
> in section .text, but it seems pretty obvious: the address range of
> the section matches, .text is the only text section, the MIPS_TEXT
> shndx name... I read various man pages, but couldn't find anything
> that explicitly says MIPS_TEXT = .text section.
> 
> So I made the following change, which allows us to recognize MIPS_TEXT.
> This fixes the symbol section to be .text, and as a consequence fixes
> the problem I've seen in GDB.
> 
> Another evidence of the change is in the new output from the same
> objdump command:
> 
> 
>         % objdump -T annota1 | grep main
>         10001658 g    DF .text        000000fc main
> 
> 2004-07-20  Joel Brobecker  <brobecker@gnat.com>
> 
>         * elfxx-mips.c (_bfd_mips_elf_symbol_processing): Add handling
>         for SHN_MIPS_TEXT symbols.
> 
> Tested on mips-irix with no regressoin, by running the following testsuites:
>   . binutils
>   . libiberty
>   . gas
>   . ld
>   . gdb
> OK to apply this patch?
> 
> Thanks,
> -- 
> Joel

> Index: elfxx-mips.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elfxx-mips.c,v
> retrieving revision 1.106
> diff -u -p -r1.106 elfxx-mips.c
> --- elfxx-mips.c	1 Jul 2004 14:53:40 -0000	1.106
> +++ elfxx-mips.c	21 Jul 2004 20:24:08 -0000
> @@ -4192,6 +4192,20 @@ _bfd_mips_elf_symbol_processing (bfd *ab
>        asym->section = bfd_und_section_ptr;
>        break;
>  
> +    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;