Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)

[Richard Earnshaw <rearnsha@arm.com>]

The following reply was made to PR target/3925; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@arm.com>
To: Philip Blundell <pb@nexus.co.uk>
Cc: Richard.Earnshaw@arm.com, gcc-gnats@gcc.gnu.org, pb@gcc.gnu.org,
        fnf@ninemoons.com, gcc-bugs@gcc.gnu.org, rearnsha@gcc.gnu.org
Subject: Re: target/3925: [ARM/Thumb] Assembler chokes on branches with 
 (PLT)
Date: Tue, 19 Mar 2002 15:09:54 +0000

 > I would be reluctant to have -shared imply PIC across the board.  There
 > are legitimate reasons why people might want to build a dynamic object
 > but not pay the cost that goes with position independence.  Perhaps this
 > is a rare enough situation that it also isn't worth losing too much
 > sleep over, I dunno.  I must admit, having -shared generate PLT relocs
 > by default for branches would go some way towards helping those people
 > who accidentally link things like libiberty.a into their shared
 > libraries.
 
 It can't mean PIC across the board, since there is no way to alter the 
 code sequences that reference static data.  The only solution will be 
 relocate the pages in question at load time.  However, the dynamic relocs 
 for that aren't any different to the relocs for the GOT (except that they 
 relocate text pages rather than data pages, and thus prevent them from 
 being shared).
 
 But for branches, my point still stands, the model to use for both types 
 of reloc is the same; and what's more, both cases would benefit from the 
 use of such a model (in one case it makes the code work when it wouldn't 
 have done otherwise, and in the second it makes the code more efficient by 
 eliminating the PLT stub when it isn't needed).
 
 R.