public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61044] Computed goto on AVR fails to use word-addressing
Date: Wed, 28 May 2014 17:29:00 -0000	[thread overview]
Message-ID: <bug-61044-4-Vah12uJjkw@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-61044-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Senthil Kumar Selvaraj from comment #3)
> The primary reason I added the diff relocs was to prevent linker relaxation
> messing up DWARF line number information - as you know, relaxation can
> shorten instruction sequences, and the addresses in DWARF then go out of
> sync.
> 
> I guess I must add some user documentation about this, but ideally, this is
> supposed to be transparent to the user - just passing -mrelax to the
> compiler should work.
> 
> I turned diff reloc generation on only if -mlink-relax is passed because
> this is what other ports (xtensa) do, and I wasn't sure of the consequences
> of resolving every subtraction expression at link time.

Resolving label differences at assemble time serves a faster linking process,
but that argument does not apply to avr:  We don't have magabytes of code that
have to be fixed at load time by a dynamic linker.

And you don't know at assemble time how the linker is called.  One example is
debugging through code that comes from a library and has been linked against
the application.  It's not very common but possible and yet another plus
(besides simplicity with less options and less GCC/Binutils dependency) for
always emitting label differences as relocs.


      parent reply	other threads:[~2014-05-28 17:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03 11:57 [Bug target/61044] New: " dinuxbg at gmail dot com
2014-05-03 12:06 ` [Bug target/61044] " dinuxbg at gmail dot com
2014-05-23  8:53 ` gjl at gcc dot gnu.org
2014-05-27 11:48 ` senthil_kumar.selvaraj at atmel dot com
2014-05-28  8:43 ` gjl at gcc dot gnu.org
2014-05-28  8:44 ` gjl at gcc dot gnu.org
2014-05-28  8:48 ` gjl at gcc dot gnu.org
2014-05-28  8:50 ` gjl at gcc dot gnu.org
2014-05-28  8:53 ` gjl at gcc dot gnu.org
2014-05-28 17:29 ` gjl at gcc dot gnu.org [this message]

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=bug-61044-4-Vah12uJjkw@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).