This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOLD] Edit PowerPC64 ELFv2 function entry code


On Tue, Dec 8, 2015 at 3:32 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Dec 08, 2015 at 02:36:12PM -0800, Cary Coutant wrote:
>> > +                 Insn* iview = reinterpret_cast<Insn*>(view - 2 * big_endian);
>> > +                 Insn insn1 = elfcpp::Swap<32, big_endian>::readval(iview - 1);
>> > +                 Insn insn2 = elfcpp::Swap<32, big_endian>::readval(iview);
>>
>> I'm afraid I don't understand this logic. As I read it, you're looking
>> at view for little-endian, and at (view - 2) for big-endian. If that's
>> the case, I think you should be using Swap_unaligned here, but I don't
>> see why you offset the view by -2 for big-endian.
>
> The reloc in question operates on a two-byte field of the four-byte
> instruction.   When the insn is little-endian the field and the insn
> start at the same address.  Not so for big-endian.

Oh, I get it now -- the r_offset field for this relocation points to
the immediate field (i.e., instruction address + 2 for big-endian),
rather than the word-aligned address of the whole instruction, so to
load the whole instruction, you need to subtract 2. (If this were x86,
it would have made sense right away, but I come from a PA-RISC and
Itanium background, and I didn't expect PPC relocations to point to
anything but the whole word-aligned instruction.)

Do you worry about proper alignment? If gold is running on a host that
doesn't support unaligned access, any misaligned relocations will
cause gold to crash. If misaligned relocations are unexpected, it
would be good to check and issue a graceful warning; if expected, you
should probably use Swap_unaligned. (x86 suffers from the same
theoretical problem: if anyone ever tries to cross-link x86 objects on
a strict-alignment host, we'll have problems.) I have a to-do, based
on some earlier conversations with Rafael, to rework the unaligned
access code so that there's no performance penalty when the host
supports unaligned access. If you do want to switch to Swap_unaligned,
you should probably wait until I've done that, so let me know.

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]