MIPS assembler no longer "combines symbols in different segments"...

MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

A recent change to gas seems to have broken it so that it no longer 
works with gcc-3.3.  Configured as target=mipsel-linux

The .eh_frame code generated by gcc-3.3 contains things like this:

         .4byte  $LFB2-.

Where '$LFB2' is in .text and '.' is in .eh_frame.  This worked well in 
2.15 but for:

$ mipsel-linux-as --version
GNU assembler 050218 20050218

I am getting:

Error: operation combines symbols in different segments

for this.

Is there a good reason that this was changed?

If not can we change it back?

There are enough ld bugs in 2.15 that I want to use this snapshot, but I 
will probably have to resolve this issue first.

David Daney.

Re: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

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

David Daney wrote:
> A recent change to gas seems to have broken it so that it no longer 
> works with gcc-3.3.  Configured as target=mipsel-linux
> 
> The .eh_frame code generated by gcc-3.3 contains things like this:
> 
>         .4byte  $LFB2-.
> 
> Where '$LFB2' is in .text and '.' is in .eh_frame.  This worked well in 
> 2.15 but for:
> 
> $ mipsel-linux-as --version
> GNU assembler 050218 20050218
> 
> I am getting:
> 
> Error: operation combines symbols in different segments
> 
> for this.
> 
> Is there a good reason that this was changed?
> 
> If not can we change it back?
> 
> There are enough ld bugs in 2.15 that I want to use this snapshot, but I 
> will probably have to resolve this issue first.
> 
> David Daney.

This patch seems like it caused this problem:

[ bfd/ChangeLog ]
2004-04-28  Chris Demetriou  <cgd@broadcom.com>

	* reloc.c: Remove BFD_RELOC_PCREL_HI16_S and BFD_RELOC_PCREL_LO16.
	* bfd-in2.h: Regenerate.
	* libbfd.h: Likewise.

[ gas/ChangeLog ]
2004-04-28  Chris Demetriou  <cgd@broadcom.com>

	* config/tc-mips.c (HAVE_32BIT_ADDRESSES, append_insn, macro_build)
	(load_address, macro, mips_ip, md_parse_option)
	(mips_force_relocation, mips_validate_fix, md_apply_fix3)
	(s_change_sec, pic_need_relax, tc_gen_reloc): Remove all
	embedded-PIC handling, and update comments.
	(SWITCH_TABLE): Remove.
	* config/tc-mips.h (DIFF_EXPR_OK): Delete.
	(enum mips_pic_level): Remove EMBEDDED_PIC.
	(EXTERN_FORCE_RELOC): Remove embedded-PIC handling.
	(TC_FORCE_RELOCATION): Update comment.
	* ecoff.c (ecoff_build_lineno): Add comment about some code that
	might be safe to remove now that MIPS embedded-PIC is gone.


The attached patch was tested with make -k check no regressions and gets 
back to the behavior I want.  But I will also do a little more testing 
before giving it my whole hearted endorsement.

2005-02-35  David Daney  <ddaney@avtrex.com>

         * config/tc-mips.h: #define DIFF_EXPR_OK.
         * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
         because DIFF_EXPR_OK generates them.
         (tc_gen_reloc) : Ditto.


Thoughts or opinions?

David Daney.




[-- Attachment #2: binutils.diff --]
[-- Type: text/plain, Size: 2054 bytes --]

diff -rcp binutils_reference/binutils-050218/gas/config/tc-mips.c binutils-050218/gas/config/tc-mips.c
*** binutils_reference/binutils-050218/gas/config/tc-mips.c	2005-02-17 05:46:04.000000000 -0800
--- binutils-050218/gas/config/tc-mips.c	2005-02-25 15:35:28.000000000 -0800
*************** md_apply_fix3 (fixS *fixP, valueT *valP,
*** 11018,11025 ****
  
    buf = (bfd_byte *) (fixP->fx_frag->fr_literal + fixP->fx_where);
  
-   assert (! fixP->fx_pcrel);
- 
    /* Don't treat parts of a composite relocation as done.  There are two
       reasons for this:
  
--- 11018,11023 ----
*************** md_apply_fix3 (fixS *fixP, valueT *valP,
*** 11065,11071 ****
      case BFD_RELOC_MIPS16_GPREL:
      case BFD_RELOC_MIPS16_HI16:
      case BFD_RELOC_MIPS16_HI16_S:
-       assert (! fixP->fx_pcrel);
        /* Nothing needed to do. The value comes from the reloc entry */
        break;
  
--- 11063,11068 ----
*************** tc_gen_reloc (asection *section ATTRIBUT
*** 12846,12852 ****
    *reloc->sym_ptr_ptr = symbol_get_bfdsym (fixp->fx_addsy);
    reloc->address = fixp->fx_frag->fr_address + fixp->fx_where;
  
-   assert (! fixp->fx_pcrel);
    reloc->addend = fixp->fx_addnumber;
  
    /* Since the old MIPS ELF ABI uses Rel instead of Rela, encode the vtable
--- 12843,12848 ----
Only in binutils-050218/gas/config: tc-mips.c~
diff -rcp binutils_reference/binutils-050218/gas/config/tc-mips.h binutils-050218/gas/config/tc-mips.h
*** binutils_reference/binutils-050218/gas/config/tc-mips.h	2004-04-28 22:14:22.000000000 -0700
--- binutils-050218/gas/config/tc-mips.h	2005-02-25 15:52:23.051225506 -0800
*************** extern void mips_handle_align (struct fr
*** 58,63 ****
--- 58,68 ----
  
  #define MAX_MEM_FOR_RS_ALIGN_CODE  (1 + 2)
  
+ /* We permit PC relative difference expressions because gcc used to
+    generate them in .eh_frame sections.  */
+ #define DIFF_EXPR_OK
+ 
+ 
  /* Tell assembler that we have an itbl_mips.h header file to include.  */
  #define HAVE_ITBL_CPU
  
Only in binutils-050218/gas/config: tc-mips.h~

Re: MIPS assembler no longer "combines symbols in different segments"...

[cgd]

Virtually all knowledge i have about this is totally paged out, but
IIRC there was some discussion about this patch related to this issue,
either on binutils or on the gcc list...

maybe Richard or Eric remember...


chris

Re: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

David Daney wrote:
> 2005-02-35  David Daney  <ddaney@avtrex.com>
> 
>         * config/tc-mips.h: #define DIFF_EXPR_OK.
>         * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
>         because DIFF_EXPR_OK generates them.
>         (tc_gen_reloc) : Ditto.
> 
> 

It seems that this breaks exception handling which is the reason for the 
patch.  Back to the drawing board...

David Daney

[Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

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

David Daney wrote:
> A recent change to gas seems to have broken it so that it no longer 
> works with gcc-3.3.  Configured as target=mipsel-linux
> 
> The .eh_frame code generated by gcc-3.3 contains things like this:
> 
>         .4byte  $LFB2-.
> 
> Where '$LFB2' is in .text and '.' is in .eh_frame.  This worked well in 
> 2.15 but for:
> 
> $ mipsel-linux-as --version
> GNU assembler 050218 20050218
> 
> I am getting:
> 
> Error: operation combines symbols in different segments
> 
> for this.
> 
> Is there a good reason that this was changed?
> 
> If not can we change it back?
> 
> There are enough ld bugs in 2.15 that I want to use this snapshot, but I 
> will probably have to resolve this issue first.
> 
> David Daney.


Attached is a patch that fixes this problem.  This one I am much more 
confident of.  It passes make check in libffi for my hacked up back 
ported to gcc-3.4.3 version.  This include the exception test that 
failed with my last patch.

make -k check with no regressions.  Oddly enough for me this fixes one 
ld XFAIL even though I am only fixing gas.

I think my copyright things are in order for binutils, but I don't think 
I have CVS write access for binutils so someone else will have to commit 
for me.


2005-02-35  David Daney  <ddaney@avtrex.com>

         * config/tc-mips.h: #define DIFF_EXPR_OK.
         * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
         because DIFF_EXPR_OK generates them.
         (tc_gen_reloc) : Handle fixP->fx_pcrel for BFD_RELOC_32 case.


David Daney.

[-- Attachment #2: binutils.diff --]
[-- Type: text/plain, Size: 3475 bytes --]

diff -rcp --exclude='*.info*' binutils_reference/binutils-050218/gas/config/tc-mips.c binutils-050218/gas/config/tc-mips.c
*** binutils_reference/binutils-050218/gas/config/tc-mips.c	2005-02-17 05:46:04.000000000 -0800
--- binutils-050218/gas/config/tc-mips.c	2005-02-25 18:46:55.277082758 -0800
*************** md_apply_fix3 (fixS *fixP, valueT *valP,
*** 11018,11025 ****
  
    buf = (bfd_byte *) (fixP->fx_frag->fr_literal + fixP->fx_where);
  
-   assert (! fixP->fx_pcrel);
- 
    /* Don't treat parts of a composite relocation as done.  There are two
       reasons for this:
  
--- 11018,11023 ----
*************** md_apply_fix3 (fixS *fixP, valueT *valP,
*** 11065,11071 ****
      case BFD_RELOC_MIPS16_GPREL:
      case BFD_RELOC_MIPS16_HI16:
      case BFD_RELOC_MIPS16_HI16_S:
-       assert (! fixP->fx_pcrel);
        /* Nothing needed to do. The value comes from the reloc entry */
        break;
  
--- 11063,11068 ----
*************** tc_gen_reloc (asection *section ATTRIBUT
*** 12846,12853 ****
    *reloc->sym_ptr_ptr = symbol_get_bfdsym (fixp->fx_addsy);
    reloc->address = fixp->fx_frag->fr_address + fixp->fx_where;
  
!   assert (! fixp->fx_pcrel);
!   reloc->addend = fixp->fx_addnumber;
  
    /* Since the old MIPS ELF ABI uses Rel instead of Rela, encode the vtable
       entry to be used in the relocation's section offset.  */
--- 12843,12865 ----
    *reloc->sym_ptr_ptr = symbol_get_bfdsym (fixp->fx_addsy);
    reloc->address = fixp->fx_frag->fr_address + fixp->fx_where;
  
!   if (fixp->fx_pcrel)
!     {
!       if (OUTPUT_FLAVOR == bfd_target_elf_flavour)
! 	{
! 	  /* At this point, fx_addnumber is "symbol offset - reloc->address".
! 	     Relocations want only the symbol offset.  */
! 	  reloc->addend = fixp->fx_addnumber + reloc->address;
! 	}
!       else
! 	{
! 	  /* A gruesome hack which is a result of the gruesome gas reloc
! 	     handling.  */
! 	  reloc->addend = reloc->address;
! 	}
!     }
!   else
!     reloc->addend = fixp->fx_addnumber;
  
    /* Since the old MIPS ELF ABI uses Rel instead of Rela, encode the vtable
       entry to be used in the relocation's section offset.  */
*************** tc_gen_reloc (asection *section ATTRIBUT
*** 12858,12863 ****
--- 12870,12885 ----
      }
  
    code = fixp->fx_r_type;
+   if (fixp->fx_pcrel)
+     {
+       if (code == BFD_RELOC_32)
+         code = BFD_RELOC_32_PCREL;
+       else
+         as_bad_where (fixp->fx_file, fixp->fx_line,
+ 		     _("Cannot make %s relocation PC relative"),
+ 		     bfd_get_reloc_code_name (code));
+     }
+   
  
    /* To support a PC relative reloc, we used a Cygnus extension.
       We check for that here to make sure that we don't let such a
Only in binutils-050218/gas/config: tc-mips.c~
diff -rcp --exclude='*.info*' binutils_reference/binutils-050218/gas/config/tc-mips.h binutils-050218/gas/config/tc-mips.h
*** binutils_reference/binutils-050218/gas/config/tc-mips.h	2004-04-28 22:14:22.000000000 -0700
--- binutils-050218/gas/config/tc-mips.h	2005-02-25 15:52:23.000000000 -0800
*************** extern void mips_handle_align (struct fr
*** 58,63 ****
--- 58,68 ----
  
  #define MAX_MEM_FOR_RS_ALIGN_CODE  (1 + 2)
  
+ /* We permit PC relative difference expressions because gcc used to
+    generate them in .eh_frame sections.  */
+ #define DIFF_EXPR_OK
+ 
+ 
  /* Tell assembler that we have an itbl_mips.h header file to include.  */
  #define HAVE_ITBL_CPU
  
Only in binutils-050218/gas/config: tc-mips.h~

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[cgd]

i do recommend assembler test cases (for both the successes and
warnings).  This stuff has tended to get messed up in the past...



chris

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Maciej W. Rozycki]

On Fri, 25 Feb 2005, David Daney wrote:

> Attached is a patch that fixes this problem.  This one I am much more
> confident of.  It passes make check in libffi for my hacked up back ported to
> gcc-3.4.3 version.  This include the exception test that failed with my last
> patch.
[...]
> 2005-02-35  David Daney  <ddaney@avtrex.com>
> 
> * config/tc-mips.h: #define DIFF_EXPR_OK.
> * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
> because DIFF_EXPR_OK generates them.
> (tc_gen_reloc) : Handle fixP->fx_pcrel for BFD_RELOC_32 case.

 Have you seen the comment about R_MIPS_PC32 in bfd/elf32-mips.c?  This is 
a GNU extension which we don't want to support for generation of new code.  
It's not even supported by elfn32-mips.c and elf64-mips.c at all, so if 
your GCC uses it for the (n)64 or the n32 ABI, it will not work anyway.

 How about updating GCC so that it does not emit these problematic 
statements?  Either your local copy or the 3.3 branch (if there is 
interest).  Using older binutils is another option.

  Maciej

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Daniel Jacobowitz]

On Mon, Feb 28, 2005 at 02:46:31PM +0000, Maciej W. Rozycki wrote:
> On Fri, 25 Feb 2005, David Daney wrote:
> 
> > Attached is a patch that fixes this problem.  This one I am much more
> > confident of.  It passes make check in libffi for my hacked up back ported to
> > gcc-3.4.3 version.  This include the exception test that failed with my last
> > patch.
> [...]
> > 2005-02-35  David Daney  <ddaney@avtrex.com>
> > 
> > * config/tc-mips.h: #define DIFF_EXPR_OK.
> > * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
> > because DIFF_EXPR_OK generates them.
> > (tc_gen_reloc) : Handle fixP->fx_pcrel for BFD_RELOC_32 case.
> 
>  Have you seen the comment about R_MIPS_PC32 in bfd/elf32-mips.c?  This is 
> a GNU extension which we don't want to support for generation of new code.  
> It's not even supported by elfn32-mips.c and elf64-mips.c at all, so if 
> your GCC uses it for the (n)64 or the n32 ABI, it will not work anyway.
> 
>  How about updating GCC so that it does not emit these problematic 
> statements?  Either your local copy or the 3.3 branch (if there is 
> interest).  Using older binutils is another option.

The comment is missing the most important piece of data - _why_ it
should no longer be used.  I don't see a legitimate reason.

I recently implemented another PIC model for MIPS, separate from
embedded-PIC but sharing a couple of properties, and this support was
extremely useful.  I haven't had the time to contribute it back yet but
I hope to sometime after 2.16.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Dave Korn]

----Original Message----
>From: binutils-owner On Behalf Of Daniel Jacobowitz
>Sent: 28 February 2005 14:52 

> On Mon, Feb 28, 2005 at 02:46:31PM +0000, Maciej W. Rozycki wrote:
>> On Fri, 25 Feb 2005, David Daney wrote:
>> 
>>> Attached is a patch that fixes this problem.  This one I am much more
>>> confident of.  It passes make check in libffi for my hacked up back
>>> ported to gcc-3.4.3 version.  This include the exception test that
>>> failed with my last patch.
>> [...]
>>> 2005-02-35  David Daney  <ddaney@avtrex.com>
>>> 
>>> * config/tc-mips.h: #define DIFF_EXPR_OK.
>>> * config/tc-mips.c (md_apply_fix3): Remove assert (!fixP->fx_pcrel)
>>> because DIFF_EXPR_OK generates them.
>>> (tc_gen_reloc) : Handle fixP->fx_pcrel for BFD_RELOC_32 case.
>> 
>>  Have you seen the comment about R_MIPS_PC32 in bfd/elf32-mips.c?  This
>> is a GNU extension which we don't want to support for generation of new
>> code. It's not even supported by elfn32-mips.c and elf64-mips.c at all,
>> so if your GCC uses it for the (n)64 or the n32 ABI, it will not work
>> anyway. 
>> 
>>  How about updating GCC so that it does not emit these problematic
>> statements?  Either your local copy or the 3.3 branch (if there is
>> interest).  Using older binutils is another option.
> 
> The comment is missing the most important piece of data - _why_ it
> should no longer be used.  I don't see a legitimate reason.
> 
> I recently implemented another PIC model for MIPS, separate from
> embedded-PIC but sharing a couple of properties, and this support was
> extremely useful.  I haven't had the time to contribute it back yet but
> I hope to sometime after 2.16.


  I agree with this:  it's an ABI-breaking change to suddenly remove support
for a reloc type.  It may be desirable for more modern versions of the
toolchain to deprecate, warn about, or simply no longer generate any given
reloc, but some people have legacy compiled .o files that they'd still like
to be linkable, and just because we don't want to generate it for new code
doesn't mean we have to break the old code out there that already uses it.
Why does the fact that it's no good for the (n)64 or n32 ABIs mean that it
has to be removed from the older ABI which it _does_ work on?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Maciej W. Rozycki]

On Mon, 28 Feb 2005, Daniel Jacobowitz wrote:

> >  How about updating GCC so that it does not emit these problematic 
> > statements?  Either your local copy or the 3.3 branch (if there is 
> > interest).  Using older binutils is another option.
> 
> The comment is missing the most important piece of data - _why_ it
> should no longer be used.  I don't see a legitimate reason.

 The relocation isn't a part of the SysV ABI and was never meant to be 
used by Linux.  Its use by GCC must have been a mistake -- someone did a 
bad implementation and it worked by accident thanks to binutils supporting 
the needed relocation for embedded-PIC targets.

> I recently implemented another PIC model for MIPS, separate from
> embedded-PIC but sharing a couple of properties, and this support was
> extremely useful.  I haven't had the time to contribute it back yet but
> I hope to sometime after 2.16.

 For another ABI it should be OK to use.  It's just it's not a part of the 
Linux ABI.

  Maciej

RE: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Maciej W. Rozycki]

On Mon, 28 Feb 2005, Dave Korn wrote:

>   I agree with this:  it's an ABI-breaking change to suddenly remove support
> for a reloc type.  It may be desirable for more modern versions of the

 It's not a breaking change -- the relocation has never been a part of the
Linux ABI.  It has simply been abused.  If you use an undocumented
feature, you shouldn't be surprised if that feature disappears one day,
sorry.

> toolchain to deprecate, warn about, or simply no longer generate any given
> reloc, but some people have legacy compiled .o files that they'd still like
> to be linkable, and just because we don't want to generate it for new code
> doesn't mean we have to break the old code out there that already uses it.

 Old .o files still work and will work for the foreseeable future as BFD 
still supports these relocations and it's not going to be changed -- have 
you actually looked at the comment I've referred to.  It's gas support 
that we discuss and that means it only affects source code.

  Maciej

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

Maciej W. Rozycki wrote:
> On Mon, 28 Feb 2005, Dave Korn wrote:
> 
> 
>>  I agree with this:  it's an ABI-breaking change to suddenly remove support
>>for a reloc type.  It may be desirable for more modern versions of the
> 
> 
>  It's not a breaking change -- the relocation has never been a part of the
> Linux ABI.  It has simply been abused.  If you use an undocumented
> feature, you shouldn't be surprised if that feature disappears one day,
> sorry.
> 

What do you consider a "breaking change"?  I don't care if it is part of 
some official ABI document.  It is part of a de facto ABI that is used 
by GCC-3.3.x

By removing this relocation, you cannot use binutils 2.16 with 
GCC-3.3.x.  In a perfect world, Binutils 2.15 would have had a 
non-broken linker and we would keep using it.  But we don't live in a 
perfect world.

I don't see what is gained in making binutils 2.16 unsuable with GCC-3.3.x.

David Daney.

RE: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Dave Korn]

----Original Message----
>From: macro On Behalf Of Maciej W. Rozycki 
>Sent: 28 February 2005 16:30

>  Old .o files still work and will work for the foreseeable future as BFD
> still supports these relocations and it's not going to be changed -- have
> you actually looked at the comment I've referred to.  It's gas support
> that we discuss and that means it only affects source code.

  Oops, pardon me, I wasn't following quite closely enough.  That of course
invalidates any concern I would have had.  Retaining the support in bfd but
changing the upper layers of the toolchain to not generate such relocs is of
course exactly the sort of approach I accepted as reasonable!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Maciej W. Rozycki]

On Mon, 28 Feb 2005, David Daney wrote:

> > It's not a breaking change -- the relocation has never been a part of the
> > Linux ABI.  It has simply been abused.  If you use an undocumented
> > feature, you shouldn't be surprised if that feature disappears one day,
> > sorry.
> > 
> 
> What do you consider a "breaking change"?  I don't care if it is part of some
> official ABI document.  It is part of a de facto ABI that is used by GCC-3.3.x

 It's a bug in GCC 3.3.  It has been fixed.  If you require 
bug-compatibility, you may maintain it yourself either by fixing GCC 3.3 
or by using your workaround.

 We don't expand the ABI every time a bug in a tool makes it go beyond 
what's already defined.

> By removing this relocation, you cannot use binutils 2.16 with GCC-3.3.x.  In
> a perfect world, Binutils 2.15 would have had a non-broken linker and we would
> keep using it.  But we don't live in a perfect world.

 In a perfect world GCC 3.3 wouldn't have had this bug.  Is backporting 
the fix from GCC 3.4 impossible?

> I don't see what is gained in making binutils 2.16 unsuable with GCC-3.3.x.

 Forcing the right bug fix instead of attempted workarounds?

  Maciej

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

Maciej W. Rozycki wrote:
> On Mon, 28 Feb 2005, David Daney wrote:
> 
> 
>>>It's not a breaking change -- the relocation has never been a part of the
>>>Linux ABI.  It has simply been abused.  If you use an undocumented
>>>feature, you shouldn't be surprised if that feature disappears one day,
>>>sorry.
>>>
>>
>>What do you consider a "breaking change"?  I don't care if it is part of some
>>official ABI document.  It is part of a de facto ABI that is used by GCC-3.3.x
> 
> 
>  It's a bug in GCC 3.3.  It has been fixed.  If you require 
> bug-compatibility, you may maintain it yourself either by fixing GCC 3.3 
> or by using your workaround.
> 

I guess I will be maintaining my own private gas work around as it now 
appears quite unlikely that the patch or something similar will ever get 
into an official binutils release.

> 
>>By removing this relocation, you cannot use binutils 2.16 with GCC-3.3.x.  In
>>a perfect world, Binutils 2.15 would have had a non-broken linker and we would
>>keep using it.  But we don't live in a perfect world.
> 
> 
>  In a perfect world GCC 3.3 wouldn't have had this bug.  Is backporting 
> the fix from GCC 3.4 impossible?
> 

Most things of this nature are not impossible.  I think messing around 
with GCC is much more risky and much more work than my patch to gas.

I am just trying to obtain a working toolchain.  I prefer to use 
unpatched official releases of things whenever possible.  My patch 
submission was just an attempt to diverge a little less.

David Daney

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Maciej W. Rozycki]

On Mon, 28 Feb 2005, David Daney wrote:

> I am just trying to obtain a working toolchain.  I prefer to use unpatched
> official releases of things whenever possible.  My patch submission was just
> an attempt to diverge a little less.

 I have the same preferences, but for the toolchain it's not possible for 
me for a few years already.  OTOH, what's wrong with GCC 3.4 that you 
can't use it?  It's been around for about a year and it's pretty stable.  
You could avoid the problem this way.

  Maciej

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[David Daney]

Maciej W. Rozycki wrote:
> On Mon, 28 Feb 2005, David Daney wrote:
> 
> 
>>I am just trying to obtain a working toolchain.  I prefer to use unpatched
>>official releases of things whenever possible.  My patch submission was just
>>an attempt to diverge a little less.
> 
> 
>  I have the same preferences, but for the toolchain it's not possible for 
> me for a few years already.  OTOH, what's wrong with GCC 3.4 that you 
> can't use it?  It's been around for about a year and it's pretty stable.  
> You could avoid the problem this way.
> 

I have backported libffi and some libgcj things from a 4.0 snapshot from 
many months ago into my 3.4.  The libffi version that I am using needs 
the 32bit PC relative relocation.  I could get libffi from the current 
4.0 and probably solve this part of the problem.

Also for a variety of non-technical reasons we have to support GCC-3.3.1 
in adition to using 3.4  It would be nice to use the same binutils 
version for both.

David Daney

Re: [Patch] was: MIPS assembler no longer "combines symbols in different segments"...

[Richard Sandiford]

David Daney <ddaney@avtrex.com> writes:
> Most things of this nature are not impossible.  I think messing around
> with GCC is much more risky and much more work than my patch to gas.

In this case I think the gcc patch is probably safer than the binutils one.
The patch you need is:

   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00970.html

Richard