Re: 2.15 branch merge

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 16, 2004, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Apr 12, 2004, Alan Modra <amodra@bigpond.net.au> wrote:
>> On Sat, Apr 10, 2004 at 12:47:15AM -0300, Alexandre Oliva wrote:
>>> I suppose I could create a new bfd arch used for object files that
>>> have the EF_FRV_FDPIC bit set, but this would suck in terms of
>>> duplication of code :-(

>> grep will show you a number of other architectures that include
>> elf32-target two or more times.  Doing that in elf32-frv.c, and making a
>> few tweaks here and there should let you do what you want without much
>> duplication.

> Ah, yes!  Cool, I'd forgotten we could do that.  It's exactly what I
> needed.

> This big patch implements your suggestion.  While at that, I thought
> I'd rename all FDPIC-specific identifiers to make it clear that
> they're FDPIC-only, which made the patch huge.  I attach a separate,
> smaller patch-lookalike that shows all non-mechanical changes
> contained in the patch.  Having a separate BFD vector has enabled
> several simplifications.

> I also include a bug fix: when linking a shared library, we wouldn't
> relocate contents of debugging sections properly.

> I also noticed that the non-PCREL exception handling patch is missing
> from the 2.15 branch.  This means FDPIC is pretty much broken, at
> least for C++, so there's little point in even trying to fix it in the
> branch.  I attach a patch for the branch anyway, after the patch for
> mainline.  They're equivalent except for the changes to the EH-related
> functions that didn't exist in the branch.

> I adjusted the testsuite to accept both bfd vector names, such that
> they'd pass in both frv-elf and frv-uclinux.  The latter defaults to
> -mfdpic in the assembler now; previously, the linker used the
> elf32frvfd emulation but object files assembled directly from source
> didn't get the FDPIC bit set, which could be confusing.

> No regressions in mainline or branch, both frv-elf and frv-uclinux
> tested, the former with --enable-targets=all.

> Is the first bzip2ed attachment ok for mainline?  Is the second ok for
> the branch?

Nick approved this change in private, so I'm checking it in mainline
as well as in the 2.15 branch (per Dan's approval conditioned on
approval for mainline).  The patch for the 2.15 branch doesn't have
the changes for fr405 and fr450 testsuite, since the files aren't
there, but I'm not bothering to post the big patch here one more
time.  The patch for mainline I posted before still applied cleanly in
mainline.  Since the EH-related patch went into the branch now, I'm
using the same patch for mainline.  It needed only two small hunks to
be applied by hand because of conflicts with the fr405 and fr450
support added to mainline in gas/config/tc-frv.c.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}