From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Richard Sandiford <rdsandiford@googlemail.com>,
M R Swami Reddy <MR.Swami.Reddy@nsc.com>
Cc: Alan Modra <amodra@gmail.com>, binutils@sourceware.org
Subject: Re: [PATCH][PR ld/10144] MIPS/BFD: Don't make debug section relocs dynamic
Date: Mon, 13 Dec 2010 16:51:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1012131233150.4142@tp.orcam.me.uk> (raw)
In-Reply-To: <871v5ozk2e.fsf@firetop.home>
On Sat, 11 Dec 2010, Richard Sandiford wrote:
> > Thanks, I'll be applying the following change on top of that change then,
> > unless you have any further concerns.
>
> I think this is likely to break other targets that have 32-bit ABIs
> and 64-bit architectures. A general fix along the lines of the
> bfd.c:is32bit thing that I mentioned upthread would be needed first.
TBH I don't think putting a lot of infrastructure into an internal
feature meant for testing only is worth the effort unless proved
otherwise. I propose to include my testcases as is now and then the
respective platform maintainers to implement TC_ADDRESS_BYTES as a need
arises, i.e. someone notices breakage or they feel like looking for work.
We've got around a year until the next release now, so there's plenty of
time to catch any problems and I find the idea of rejecting a test case
because "it may reveal breakage somewhere" backwards, sorry. This is
exactly what test cases are for.
If enough evidence is found this is worth abstracting, then the
bfd.c:is32bit idea you propose may be implemented (though I'd be more
comfortable with a function returning a quantitative result -- there are
undoubtedly addressing submode variations other to 64/32, e.g. 32/16,
24/16, etc.). The TC_ADDRESS_BYTES macro is distinct enough for all the
places to be easily identified at that stage.
As I believe these test cases are good enough in the current form, I will
not make any further development in this area. I'll be happy to commit my
proposal as posted, but otherwise I'll dismiss it -- feel free to pick it
up yourself, share with somebody or discard altogether.
> (That fix would also have worked for your three examples, without
> the need for a MIPS-specific patch. The reason I didn't insist
> is that a MIPS-specific change is needed for EABI64 (32-bit ELF,
> 64-bit addresses, ick.).)
Well, I believe TC_ADDRESS_BYTES is the least of concern with getting the
address size right.
While at it: M R Swami, as the CR16 maintainer would you please have a
look at CR16 implementation of l_cons() in gas/config/tc-cr16.c? This
function refers to TC_ADDRESS_BYTES that is nowhere defined in that
configuration and the .dc.a pseudo-op is therefore likely broken for that
target. I suspect the function has been copied and pasted from gas/read.c
without the bit referring to TC_ADDRESS_BYTES updated accordingly. Thank
you.
Maciej
next prev parent reply other threads:[~2010-12-13 13:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-14 23:31 Maciej W. Rozycki
2010-09-18 8:40 ` Richard Sandiford
2010-11-04 15:09 ` Maciej W. Rozycki
2010-11-04 17:28 ` Richard Sandiford
2010-11-04 17:48 ` Maciej W. Rozycki
2010-11-10 17:16 ` Richard Sandiford
2010-11-10 17:58 ` Maciej W. Rozycki
2010-11-11 0:27 ` Matthias Klose
2010-11-11 1:44 ` Maciej W. Rozycki
2010-11-11 10:11 ` Richard Sandiford
2010-11-12 17:39 ` Maciej W. Rozycki
2010-11-15 8:32 ` Alan Modra
2010-12-07 20:27 ` Maciej W. Rozycki
2010-12-09 21:20 ` Richard Sandiford
2010-12-10 14:32 ` Maciej W. Rozycki
2010-12-11 10:21 ` Richard Sandiford
2010-12-13 16:51 ` Maciej W. Rozycki [this message]
2011-10-31 12:22 ` Maciej W. Rozycki
2011-11-24 20:59 ` Richard Sandiford
2011-11-29 12:43 ` Maciej W. Rozycki
2011-12-01 2:52 ` Fix CRIS bug exposed by "MIPS/BFD: Don't make debug section relocs dynamic" Hans-Peter Nilsson
2011-12-01 8:14 ` Tristan Gingold
2011-12-01 10:46 ` Mikael Pettersson
2011-12-01 15:52 ` nick clifton
2011-12-02 8:12 ` Tristan Gingold
2011-12-02 12:12 ` Hans-Peter Nilsson
2011-12-02 12:50 ` Tristan Gingold
2011-12-02 13:39 ` Hans-Peter Nilsson
2012-02-15 23:03 ` [PATCH] de-Linuxification Thomas Schwinge
2012-02-20 1:53 ` Alan Modra
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=alpine.DEB.1.10.1012131233150.4142@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=MR.Swami.Reddy@nsc.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=rdsandiford@googlemail.com \
/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).