public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: pb@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: target/3925: [ARM/Thumb] Assembler chokes on branches with (PLT)
Date: Tue, 19 Mar 2002 03:16:00 -0000	[thread overview]
Message-ID: <20020319111604.2280.qmail@sources.redhat.com> (raw)

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.


             reply	other threads:[~2002-03-19 11:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-19  3:16 Richard Earnshaw [this message]
2002-03-19  3:40 rearnsha
2002-03-19  3:56 Philip Blundell
2002-03-19  4:06 Richard Earnshaw
2002-03-19  6:36 Philip Blundell
2002-03-19  6:56 Richard Earnshaw
2002-03-19  7:06 Philip Blundell
2002-03-19  7:16 Richard Earnshaw
2002-03-19  7:26 Philip Blundell
2002-03-19  7:36 Richard Earnshaw
2002-04-23  8:57 rearnsha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020319111604.2280.qmail@sources.redhat.com \
    --to=rearnsha@arm.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=pb@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).