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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

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

[-- Attachment #2: elfxx-mips.c.diff --]
[-- Type: text/plain, Size: 977 bytes --]

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;

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

[Joel Brobecker]

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;

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

[Thiemo Seufer]

Joel Brobecker wrote:
> 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?
[snip]
> > @@ -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;

The last three lines in this patch suggest AFAICS to use
mips_elf_text_section_ptr instead of bfd_get_section_by_name,
and to make the test conditional on SGI_COMPAT. The SHN_MIPS_DATA
below should probably get handled similiarily.


Thiemo

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

[Mark Kettenis]

   From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
   Date: Fri, 30 Jul 2004 00:19:04 +0200

   Joel Brobecker wrote:
   > 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?

Joel, I'm seeing similar problems on NetBSD/mips (NetBSD/pmax 1.6.2 to
be precise).

   [snip]

   > >  #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,
   and to make the test conditional on SGI_COMPAT. The SHN_MIPS_DATA
   below should probably get handled similiarily.

Well, mips_elf_text_section_ptr doesn't really exist.

Mark

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

[Joel Brobecker]

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

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

[Thiemo Seufer]

Mark Kettenis wrote:
>    From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
>    Date: Fri, 30 Jul 2004 00:19:04 +0200
> 
>    Joel Brobecker wrote:
>    > 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?
> 
> Joel, I'm seeing similar problems on NetBSD/mips (NetBSD/pmax 1.6.2 to
> be precise).

AFAICS it will hit all elf{32-,32-n,64-}{big,little}mips targets (as
opposed to *trad*mips), which are covered by SGI_COMPAT.

>    [snip]
> 
>    > >  #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,
>    and to make the test conditional on SGI_COMPAT. The SHN_MIPS_DATA
>    below should probably get handled similiarily.
> 
> Well, mips_elf_text_section_ptr doesn't really exist.

Right, that appears to be some leftover of earlier code. Looks like
elf_tdata()->elf_text_section replaced it.

Joel, can you try the appended (untested) patch and tell me if it
works for you?


Thiemo


Index: bfd/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
--- bfd/elfxx-mips.c	1 Jul 2004 14:53:40 -0000	1.106
+++ bfd/elfxx-mips.c	30 Jul 2004 00:28:55 -0000
@@ -4192,15 +4192,31 @@ _bfd_mips_elf_symbol_processing (bfd *ab
       asym->section = bfd_und_section_ptr;
       break;
 
-#if 0 /* for SGI_COMPAT */
     case SHN_MIPS_TEXT:
-      asym->section = mips_elf_text_section_ptr;
+      {
+	asection *section = elf_tdata (abfd)->elf_text_section;
+
+	BFD_ASSERT (SGI_COMPAT (abfd));
+	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;
 
     case SHN_MIPS_DATA:
-      asym->section = mips_elf_data_section_ptr;
+      {
+	asection *section = elf_tdata (abfd)->elf_data_section;
+
+	BFD_ASSERT (SGI_COMPAT (abfd));
+	if (section != NULL)
+	  asym->section = section;
+      }
       break;
-#endif
     }
 }
 \f

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

[Eli Zaretskii]

> Date: Fri, 30 Jul 2004 02:31:38 +0200
> From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
> 
> > Joel, I'm seeing similar problems on NetBSD/mips (NetBSD/pmax 1.6.2 to
> > be precise).
> 
> AFAICS it will hit all elf{32-,32-n,64-}{big,little}mips targets (as
> opposed to *trad*mips), which are covered by SGI_COMPAT.

Should we release a version of GDB that has so many platforms badly
broken?  Andrew?

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

[Andrew Cagney]

>>Date: Fri, 30 Jul 2004 02:31:38 +0200
>>> From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
>>> 
>>
>>>> > Joel, I'm seeing similar problems on NetBSD/mips (NetBSD/pmax 1.6.2 to
>>>> > be precise).
>>
>>> 
>>> AFAICS it will hit all elf{32-,32-n,64-}{big,little}mips targets (as
>>> opposed to *trad*mips), which are covered by SGI_COMPAT.
> 
> 
> Should we release a version of GDB that has so many platforms badly
> broken?  Andrew?

The issue is fortunatly confined to MIPS.  The announcement will make 
that clear.  We can then proceed with fixing it in mainline and either 
backporting to 6.2.1 or moving on to 6.3.

Andrew

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

[Eli Zaretskii]

> Date: Fri, 30 Jul 2004 09:36:53 -0400
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > Should we release a version of GDB that has so many platforms badly
> > broken?  Andrew?
> 
> The issue is fortunatly confined to MIPS.

So?  Are we abandoning MIPS support?

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

[Joel Brobecker]

Hello Thiemo,


> Right, that appears to be some leftover of earlier code. Looks like
> elf_tdata()->elf_text_section replaced it.
> 
> Joel, can you try the appended (untested) patch and tell me if it
> works for you?

I tried your patch, but unfortunately it doesn't work :-(. The reason
is that elf_tdata (abfd)->elf_text_section is NULL. I looked at the
code, and elf-bfd.h tells me that this field is IRIX-specific. Then
searching for the places where this field is set only turns up one
location: _bfd_mips_elf_add_symbol_hook(). And according to the comment
above it, it's only used for linking...

So this leaves us with 2 options:

  1. Do a search for the .text and .data sections by name

  2. Find a place somewhere where we can set these fields before we
     need to use them. If we have a hook for instance after we've
     read the ELF header, or while iterating over the different sections
     (I don't know the code, so I'm just tossing ideas).
     
     Or another approach would be to check that field, and if null
     then do the lookup by name and store it in elf_tdata
     (abfd)->elf_text_section for all the following symbols.
     This is just an optimized variation of 1, really.

What do you think?

Thanks,
-- 
Joel

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

[Joel Brobecker]

> > The issue is fortunatly confined to MIPS.
> 
> So?  Are we abandoning MIPS support?

I don't think so. I certainly hope not :-).  My feeling is that it is
simply too late for 6.2. But we can work towards having a good 6.2.1.

This is my fault really. I didn't realize that there was no IRIX
maintainer, so this port was left bitrotting. I should have paid more
attention to it. I will focus more on it in the future, just as I focus
more on the AIX port now.

(Michael, please feel free to nag me if you don't see regular testsuite
reports for IRIX being sent to gdb-testers)

-- 
Joel

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

[Joel Brobecker]

Thiemo,

One more thing I forgot about your patch:

>      case SHN_MIPS_DATA:
> -      asym->section = mips_elf_data_section_ptr;
> +      {
> +	asection *section = elf_tdata (abfd)->elf_data_section;
> +
> +	BFD_ASSERT (SGI_COMPAT (abfd));
> +	if (section != NULL)
> +	  asym->section = section;
> +      }
>        break;

I think that addresses for MIPS_DATA symbols follow the same rule
as in MIPS_TEXT: These are absolute addresses, so we need to substract
the section base address as well, to turn them into offsets. I verified
this empirically by inspecting an executable that had some MIPS_DATA
symbols.

-- 
Joel

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

[Eli Zaretskii]

> Date: Fri, 30 Jul 2004 11:13:53 -0700
> From: Joel Brobecker <brobecker@gnat.com>
> 
> > > The issue is fortunatly confined to MIPS.
> > 
> > So?  Are we abandoning MIPS support?
> 
> I don't think so. I certainly hope not :-).  My feeling is that it is
> simply too late for 6.2. But we can work towards having a good 6.2.1.

What's to prevent us from holding 6.2 until this bug is resolved?
What's the rush to put out a release with broken MIPS support?

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

[Joel Brobecker]

> What's to prevent us from holding 6.2 until this bug is resolved?
> What's the rush to put out a release with broken MIPS support?

Andrew probably has reasons for not delaying the release, and
I respect them.

I would be pleased if we delayed 6.2 for IRIX. But the fact of the
matter is that I discovered the fact while the first 6.2 tarball
was being made, and I also don't know how long we would need to delay it
before we could get IRIX back into a releasable shape. So I can't ask
for the delay, especially since IRIX support in 6.0 and 6.1 was broken
too.

Part of the problem with the unknown delay is with the fact that
one patch is out of our control (I am actively discussing with a BFD
mantainer, so hopefully we'll have a resolution soon), and the other
part of the problem is that the other 2 GDB patches apparently need
more work (On one of them, Andrew thinks we need some reorganization
to take place before my patch can go in, and on the other he wants
the patch to be more complete). I personally think that we are letting
the best be the enemy of good, as we could have a much better GDB right
now with a couple of adjustements left for later, but it's not my decision.

-- 
Joel

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

[Thiemo Seufer]

Joel Brobecker wrote:
[snip]
> So this leaves us with 2 options:
> 
>   1. Do a search for the .text and .data sections by name
> 
>   2. Find a place somewhere where we can set these fields before we
>      need to use them. If we have a hook for instance after we've
>      read the ELF header, or while iterating over the different sections
>      (I don't know the code, so I'm just tossing ideas).
>      
>      Or another approach would be to check that field, and if null
>      then do the lookup by name and store it in elf_tdata
>      (abfd)->elf_text_section for all the following symbols.
>      This is just an optimized variation of 1, really.

I prefer the first. Please test this patch.


Thiemo


Index: bfd/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
--- bfd/elfxx-mips.c	1 Jul 2004 14:53:40 -0000	1.106
+++ bfd/elfxx-mips.c	30 Jul 2004 18:53:18 -0000
@@ -4192,15 +4192,37 @@ _bfd_mips_elf_symbol_processing (bfd *ab
       asym->section = bfd_und_section_ptr;
       break;
 
-#if 0 /* for SGI_COMPAT */
     case SHN_MIPS_TEXT:
-      asym->section = mips_elf_text_section_ptr;
+      {
+	asection *section = bfd_get_section_by_name (abfd, ".text");
+
+	BFD_ASSERT (SGI_COMPAT (abfd));
+	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;
 
     case SHN_MIPS_DATA:
-      asym->section = mips_elf_data_section_ptr;
+      {
+	asection *section = bfd_get_section_by_name (abfd, ".data");
+
+	BFD_ASSERT (SGI_COMPAT (abfd));
+	if (section != NULL)
+	  {
+	    asym->section = section;
+	    /* MIPS_DATA is a bit special, the address is not an offset
+	       to the base of the .data section.  So substract the section
+	       base address to make it an offset.  */
+	    asym->value -= section->vma;
+	  }
+      }
       break;
-#endif
     }
 }
 \f

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

[Eli Zaretskii]

> Date: Fri, 30 Jul 2004 11:55:13 -0700
> From: Joel Brobecker <brobecker@gnat.com>
> 
> > What's to prevent us from holding 6.2 until this bug is resolved?
> > What's the rush to put out a release with broken MIPS support?
> 
> Andrew probably has reasons for not delaying the release, and
> I respect them.

Andrew?

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

[Andrew Cagney]

[The following isn't quite what joel wrote]
> We would all be pleased if we delayed 6.2 for IRIX. But the fact of the
> matter is that we only discovered the problem while the first 6.2 tarball
> was being made, and we also don't know how long we would need to delay it
> before we could get IRIX back into a releasable shape. So we can't ask
> for the delay, especially since IRIX support in 6.0 and 6.1 was broken
> too.

Right.

We'll get the MIPS back on track with either 6.2.1 in a few weeks, or 
6.3 in a few months.

Andrew

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

[Mark Kettenis]

   Date: Fri, 30 Jul 2004 20:57:28 +0200
   From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>

   I prefer the first. Please test this patch.

This patch fixes the problems for me on NetBSD/pmax.

Thanks,

Mark

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

[Michael Chastain]

Joel Brobecker <brobecker@gnat.com> wrote:
> So I can't ask for the delay, especially since IRIX support in 6.0 and
> 6.1 was broken too.

This part makes it acceptable to me.  My goal is that anybody who has
gdb N can upgrade to gdb N+1 without getting hurt.  So it's true for
mips-irix in a vicious way.

Michael C

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

[Joel Brobecker]

Thiemo,

> I prefer the first. Please test this patch.

I successfully tested this patch using the following testsuites:
  - binutils
  - libiberty
  - gas
  - ld
without any regression.

I also verified that the problem fixes the GDB problem on IRIX,
and ran the gdb-testsuite with success as well.

I think we can commit this patch :-). I have write privs, if this
can save you a couple minutes.

> Index: bfd/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
> --- bfd/elfxx-mips.c	1 Jul 2004 14:53:40 -0000	1.106
> +++ bfd/elfxx-mips.c	30 Jul 2004 18:53:18 -0000
> @@ -4192,15 +4192,37 @@ _bfd_mips_elf_symbol_processing (bfd *ab
>        asym->section = bfd_und_section_ptr;
>        break;
>  
> -#if 0 /* for SGI_COMPAT */
>      case SHN_MIPS_TEXT:
> -      asym->section = mips_elf_text_section_ptr;
> +      {
> +	asection *section = bfd_get_section_by_name (abfd, ".text");
> +
> +	BFD_ASSERT (SGI_COMPAT (abfd));
> +	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;
>  
>      case SHN_MIPS_DATA:
> -      asym->section = mips_elf_data_section_ptr;
> +      {
> +	asection *section = bfd_get_section_by_name (abfd, ".data");
> +
> +	BFD_ASSERT (SGI_COMPAT (abfd));
> +	if (section != NULL)
> +	  {
> +	    asym->section = section;
> +	    /* MIPS_DATA is a bit special, the address is not an offset
> +	       to the base of the .data section.  So substract the section
> +	       base address to make it an offset.  */
> +	    asym->value -= section->vma;
> +	  }
> +      }
>        break;
> -#endif
>      }
>  }
>  \f

Thanks,
-- 
Joel

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

[Thiemo Seufer]

Joel Brobecker wrote:
> Thiemo,
> 
> > I prefer the first. Please test this patch.
> 
> I successfully tested this patch using the following testsuites:
>   - binutils
>   - libiberty
>   - gas
>   - ld
> without any regression.
> 
> I also verified that the problem fixes the GDB problem on IRIX,
> and ran the gdb-testsuite with success as well.
> 
> I think we can commit this patch :-). I have write privs, if this
> can save you a couple minutes.

I applied the patch.


Thiemo

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

[David Anderson]

oel Brobecker <brobecker@gnat.com> writes:
>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.
>...
>
>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.


SHN_MIPS_TEXT is not mentioned in the ABI books (for any IRIX ABI).
It is set as the section for defined externals in text (normally
this means instructions). (set by ld(1) I mean.)

Nor is SHN_MIPS_DATA (used similarly, but for non-instruction externals).

IRIX ld has created things this way for a very long time.
It should be documented, but is not.  I will see about
documenting it.  I don't know why it is done this way.

Hope this helps.
David B. Anderson davea at sgi dot com http://reality.sgiweb.org/davea