From: Richard Sandiford <rdsandiford@googlemail.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: binutils@sourceware.org, gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: RFC: Adding non-PIC executable support to MIPS
Date: Mon, 28 Jul 2008 23:24:00 -0000 [thread overview]
Message-ID: <87bq0h23re.fsf@firetop.home> (raw)
In-Reply-To: <488CEA74.4060505@codesourcery.com> (Mark Mitchell's message of "Sun\, 27 Jul 2008 14\:36\:52 -0700")
Mark Mitchell <mark@codesourcery.com> writes:
> Richard Sandiford wrote:
>> Daniel Jacobowitz <dan@debian.org> writes:
>>> All comments welcome - Richard, especially from you. How would you
>>> like to proceed? I think the first step should be to get your other
>>> binutils/gcc patches merged, including MIPS16 PIC; I used those as a
>>> base. But see a few of the notes for potential problems with those
>>> patches.
>>
>> Yeah, Nick's approved most of the remaining binutils changes (thanks).
>> I haven't applied them yet because of the doubt over whether st_size
>> should be even or odd for ISA-encoded MIPS16 symbols. I don't really
>> have an opinion, so I'll accept a maintainerly decision...
>
> [I'm not sure if this is a helpful suggestion or not, so feel free to
> ignore it if it's not.]
>
> I would suggest that st_size be the actual size of the function, as it
> lives in memory. A test of it's start/end location is "could I stick a
> random data byte there and have it affect the function". For example,
> for a Thumb function whose ISA address is "0x00000001", I would consider
> for size purposes that it starts at "0x00000000", since altering that
> byte at run-time would change the meaning of the function.
For the record, my reasoning when picking the odd st_size was similar,
but with the opposite outcome. The point of using an ISA-encoded
st_value is that that's what most users want. Most of them won't
even have code to say "is this a MIPS16 symbol?".
So if users are going to get into the habit of using MIPS st_values
without checking the "ISA bit", I thought it was more conservative to
base the end address on the unmodified st_value rather than the modified
one. In other words, I thought it was more conservative to have
"st_value + st_size" be the end point of the function, rather than
"(st_value & ~1) + st_size". This ensures that "st_value" and
"st_value + st_size - 1" are bytes in the function, rather than making
"st_value + st_size" be two bytes past the end of the function (and thus
making "st_value + st_size - 1" refer to something outside the function).
But like I say, I can see there are pros and cons both ways, so I don't
really have an opinion. I'm happy to (and do) accpet Dan's decision.
And I guess the ARM experience shows that my concern isn't really an
issue in practice anyway.
Richard
prev parent reply other threads:[~2008-07-28 19:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-28 17:59 Richard Sandiford
[not found] ` <48694927.90906@cisco.com>
2008-06-30 21:20 ` Daniel Jacobowitz
2008-07-01 20:44 ` Daniel Jacobowitz
2008-07-01 21:28 ` Richard Sandiford
2008-07-01 23:14 ` Richard Sandiford
2008-07-02 8:46 ` Adam Nemet
2008-07-02 11:16 ` Thiemo Seufer
2008-07-02 12:15 ` Daniel Jacobowitz
2008-07-02 20:30 ` Richard Sandiford
2008-07-02 22:54 ` Daniel Jacobowitz
2008-07-24 16:35 ` Daniel Jacobowitz
2008-07-24 20:57 ` Daniel Jacobowitz
2008-07-24 21:01 ` Richard Sandiford
2008-07-24 21:13 ` Daniel Jacobowitz
2008-07-27 11:19 ` Richard Sandiford
2008-07-27 23:48 ` Mark Mitchell
2008-07-28 23:24 ` Richard Sandiford [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=87bq0h23re.fsf@firetop.home \
--to=rdsandiford@googlemail.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=linux-mips@linux-mips.org \
--cc=mark@codesourcery.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).