This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFA] MIPS_TEXT symbols should be associated to .text section?
- From: Joel Brobecker <brobecker at gnat dot com>
- To: binutils at sources dot redhat dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 29 Jul 2004 15:01:56 -0700
- Subject: Re: [RFA] MIPS_TEXT symbols should be associated to .text section?
- References: <20040721204604.GN1278@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;