linux-mips
[Top] [All Lists]

Re: RFC: Adding non-PIC executable support to MIPS

To: binutils@sourceware.org, gcc@gcc.gnu.org, linux-mips@linux-mips.org, rdsandiford@googlemail.com
Subject: Re: RFC: Adding non-PIC executable support to MIPS
From: Mark Mitchell <mark@codesourcery.com>
Date: Sun, 27 Jul 2008 14:36:52 -0700
In-reply-to: <87y73nelq8.fsf@firetop.home>
Organization: CodeSourcery, Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <87y74pxwyl.fsf@firetop.home> <20080724161619.GA18842@caradoc.them.org> <87y73nelq8.fsf@firetop.home>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)
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.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

<Prev in Thread] Current Thread [Next in Thread>