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

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

[Philip Blundell]

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

From: Philip Blundell <pb@nexus.co.uk>
To: Richard.Earnshaw@arm.com
Cc: 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: 19 Mar 2002 15:02:04 +0000

 On Tue, 2002-03-19 at 14:53, Richard Earnshaw wrote:
 > Given the above, my assertion is that the rules for PLT32 and PC24 are now 
 > the same, and that these aren't distinct relocations at all -- if we are 
 > putting the code into a shared library, then we must indirect through a 
 > PLT stub unless we know the function to be local (and static).  If we 
 > aren't (generating a shared library) then we need only indirect through 
 > such a stub if we need to access another module.  The linker already knows 
 > whether it is producing a shared library or not, so this isn't adding 
 > anything new.
 
 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.
 
 p.
 

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

[rearnsha]

Synopsis: [ARM/Thumb] Assembler chokes on branches with (PLT)

Responsible-Changed-From-To: pb->rearnsha
Responsible-Changed-By: rearnsha
Responsible-Changed-When: Tue Apr 23 08:57:01 2002
Responsible-Changed-Why:
    .
State-Changed-From-To: analyzed->suspended
State-Changed-By: rearnsha
State-Changed-When: Tue Apr 23 08:57:01 2002
State-Changed-Why:
    The correct way to resolve this will depend on the outcome of
    the ARM EABI review -- that is, whether a new relocation
    type should be added to handle thumb branch instructions 
    in PIC mode, or whether the existing relocations should
    be re-interpreted.  I'm suspending this bug until such
    time as the correct approach is known.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3925

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

[Richard Earnshaw]

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:25:46 +0000

 pb@nexus.co.uk said:
 > My point was that there are cases where people want to build a "shared
 > object" (in the sense of "gcc -shared") but don't ever intend to have
 > more than one copy of it resident in memory at once.  In that
 > situation, having relocations in the text section is sometimes
 > acceptable for the sake of saving the time and space that is required
 > for the PLT. 
 
 I think that would be better done by adding some sort of import-list 
 support to the linker.  Then only symbols in the import list would need to 
 go through a PLT, and all others could be resolved internally.  For 
 compatible behaviour of course, no import list would imply that all 
 symbols are potentially imported.
 
 R.
 

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

[Philip Blundell]

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

From: Philip Blundell <pb@nexus.co.uk>
To: Richard.Earnshaw@arm.com
Cc: 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: 19 Mar 2002 15:19:53 +0000

 On Tue, 2002-03-19 at 15:09, Richard Earnshaw wrote:
 > 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 
 
 Yeah, I was only talking about branches.
 
 My point was that there are cases where people want to build a "shared
 object" (in the sense of "gcc -shared") but don't ever intend to have
 more than one copy of it resident in memory at once.  In that situation,
 having relocations in the text section is sometimes acceptable for the
 sake of saving the time and space that is required for the PLT.
 
 At the moment, you can get exactly that effect by compiling without
 -fPIC and linking with "gcc -shared".  If -shared was made to imply
 function calls via PLT, that would no longer be possible.
 
 > (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).
 
 It's only an efficiency issue rather than a correctness one in both
 cases.  If you build a shared library with PC24 relocs, the dynamic
 linker will just modify your text segment in place - the pages will be
 dirtied, but your program will still work.  If the offset doesn't fit in
 24 bits, the dynamic linker will synthesize a PLT equivalent for you at
 run time.  (In theory, there are situations where the latter wouldn't be
 possible, but in practice I haven't heard of anyone having problems.)
 
 p.
 

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

[Richard Earnshaw]

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.
 

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

[Richard Earnshaw]

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 14:53:23 +0000

 > On Tue, 2002-03-19 at 11:55, Richard Earnshaw wrote:
 > > OK, so that clears up that side of the problem.  Now, what about the issue 
 > > that PLT32 and ARM24 aren't really different relocs?
 > 
 > Well, that depends on your point of view.
 > 
 > Obviously they are the same in terms of the fundamental bit operations
 > that they perform on the instruction.  But the PLT32 reloc has some
 > extra semantics stacked on top: if the symbol isn't known to be local,
 > it generates a plt entry and redirects the branch through it.
 
 I realise that, however I don't think that in reality this is any 
 different from the semantics required for PC24.
 
 > You could more or less dispose of the issue by adding an option to the
 > linker to say you wanted to generate a PIC executable.
 
 There are four cases I believe we need to consider:
 
 1) Putting non-PIC code into the static part of a program (normal case)
 2) Putting PIC code into a shared library (normal shared-library case)
 3) Putting PIC code into the static part of a program
 4) Putting non-PIC code into a (shared) library.
 
 It is understood that 3 and 4 may not result in the most efficient code; 
 in particular case 4 may mean that code pages cannot be shared (since they 
 are no-longer position independent and may need relocating at load time).  
 But they are required to execute correctly.
 
 >  If that was set,
 > you would treat all PC24 relocs like PLT32s are now; if not, you would
 > treat them as straight PC24.  I think the situation where someone is
 > deliberately mixing PIC and PDC objects in order to get a hybrid output
 > file is rare enough that it can be neglected.  On the other hand, people
 > are accustomed to controlling this with -fPIC at the compilation stage,
 > and changing it to be a linker option might turn out to be a nightmare.
 
 Given the above, my assertion is that the rules for PLT32 and PC24 are now 
 the same, and that these aren't distinct relocations at all -- if we are 
 putting the code into a shared library, then we must indirect through a 
 PLT stub unless we know the function to be local (and static).  If we 
 aren't (generating a shared library) then we need only indirect through 
 such a stub if we need to access another module.  The linker already knows 
 whether it is producing a shared library or not, so this isn't adding 
 anything new.
 
 R.
 

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

[Philip Blundell]

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

From: Philip Blundell <pb@nexus.co.uk>
To: Richard.Earnshaw@arm.com
Cc: 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: 19 Mar 2002 14:32:39 +0000

 On Tue, 2002-03-19 at 11:55, Richard Earnshaw wrote:
 > OK, so that clears up that side of the problem.  Now, what about the issue 
 > that PLT32 and ARM24 aren't really different relocs?
 
 Well, that depends on your point of view.
 
 Obviously they are the same in terms of the fundamental bit operations
 that they perform on the instruction.  But the PLT32 reloc has some
 extra semantics stacked on top: if the symbol isn't known to be local,
 it generates a plt entry and redirects the branch through it.
 
 You could more or less dispose of the issue by adding an option to the
 linker to say you wanted to generate a PIC executable.  If that was set,
 you would treat all PC24 relocs like PLT32s are now; if not, you would
 treat them as straight PC24.  I think the situation where someone is
 deliberately mixing PIC and PDC objects in order to get a hybrid output
 file is rare enough that it can be neglected.  On the other hand, people
 are accustomed to controlling this with -fPIC at the compilation stage,
 and changing it to be a linker option might turn out to be a nightmare.
 
 p.
 

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

[Richard Earnshaw]

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 <rearnsha@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 11:55:57 +0000

 > There's no reason that -k couldn't cause the assembler to emit all
 > branches as PLT32 relocs rather than PC24.  It just happens that Pat and
 > Scott chose to follow the example of the i386-linux port, where the
 > assembler just ignores -k altogether and the compiler adds "@plt"
 > decorations to call instructions.
 
 OK, so that clears up that side of the problem.  Now, what about the issue 
 that PLT32 and ARM24 aren't really different relocs?
 
 R.
 

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

[Philip Blundell]

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

From: Philip Blundell <pb@nexus.co.uk>
To: Richard Earnshaw <rearnsha@arm.com>
Cc: 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: 19 Mar 2002 11:50:08 +0000

 On Tue, 2002-03-19 at 11:09, Richard Earnshaw wrote:
 > Even if it could be shown that the two relocation types must be
 > different, then there is no reason for annotating the label in this
 > way.  When assembling PIC code all BL type instructions should generate
 > a PLT32 relocation (assuming any relocation is required at all) and when
 > not generating PIC code all BL type instructions should generate an
 > arm24 relocation.  Hence it is possible to determine the relocation type
 > required simply by the presence of the -k flag on the assembler command
 > line: no annotation of the labels is required.
 
 Yes, quite.
 
 There's no reason that -k couldn't cause the assembler to emit all
 branches as PLT32 relocs rather than PC24.  It just happens that Pat and
 Scott chose to follow the example of the i386-linux port, where the
 assembler just ignores -k altogether and the compiler adds "@plt"
 decorations to call instructions.
 
 I don't see any particularly compelling arguments for either approach
 over the other, to be honest.  It would be easy enough to make gas take
 notice of -k, and then gcc could do whatever it likes.
 
 p.
 

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

[rearnsha]

Synopsis: [ARM/Thumb] Assembler chokes on branches with (PLT)

State-Changed-From-To: feedback->analyzed
State-Changed-By: rearnsha
State-Changed-When: Tue Mar 19 03:40:12 2002
State-Changed-Why:
    [RWE] I think it's still open to question whether gcc is doing
    the right thing here.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3925

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

[Richard Earnshaw]

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

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

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3925
 
 I'm still not convinced by the need for (PLT) annotations at all.  The
 arguments that led to their creation don't seem to be correct, as far as
 I can tell.
 
 My understanding is as follows:
 
 1) The linker needs to do something different to a BL instruction when
 producing a shared library.
 2) In order to do this, the relocation type must be different.
 
 However, I strongly believe that 2 is false.  The reasons are as
 follows.
 
 1) When building a shared library, whatever we do to a PLT32 type
 relocation we must also do to a arm24 type relocation, since we have to
 be able to support non-pic code in a shared library.
 2) When not building a shared library, whatever we do to a arm24 type
 relocation we must also do to a PLT32 relocation.
 
 It therefore follows that the two are really the same, and the
 justification for their separate existence is incorrect.
 
 Even if it could be shown that the two relocation types must be
 different, then there is no reason for annotating the label in this
 way.  When assembling PIC code all BL type instructions should generate
 a PLT32 relocation (assuming any relocation is required at all) and when
 not generating PIC code all BL type instructions should generate an
 arm24 relocation.  Hence it is possible to determine the relocation type
 required simply by the presence of the -k flag on the assembler command
 line: no annotation of the labels is required.
 
 R.