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

["Dave Korn" <dave dot korn at artimi dot com>]

----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....