This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch bfd/mach-o] some tweaks to bfd_mach_o_canonicalize_one_reloc
On Feb 23, 2012, at 9:59 AM, Iain Sandoe wrote:
> Hi Tristan,
> On 23 Feb 2012, at 08:28, Tristan Gingold wrote:
>
>> Thank you for fixing this issue, I was not sure about the endiannes when I wrote this code and I don't have access anymore to a ppc darwin system.
>
> It's not necessary to have a PPC system (the problem I saw was trying to objdump PPC code on an x86 system) - it will affect any case where the endian-ness is different between host & target.
>
> I was using:
> echo " .long _foo " | as -arch ppc -o t.o
> as a test-case ;)
Ah ok.
> [I see the problem on x86 because I have a partial port to PPC enabled, which means that objdump is now able to list PPC relocs - I can send you a patch, off-list if you like (it's not ready to post yet)].
>
> I'll look at moving the representation to bytes - getting rid of the r_symbolnum field would probably be quite easy.
>
> .. but it's bit-field layout within bytes that's the issue, so I think we still would need:
>
> union {
> unsigned char access;
> struct
> {
> unsigned char r_pcrel:1, r_length:2, r_extern:1, r_type:4;
> } rev;
> {
> unsigned char r_type:4, r_extern:1, r_length:2, r_pcrel:1;
> } fwd;
> } bfd_mach_o_reloc_field_swap;
>
> ... or a set of macros to do the same.
Yes, a set of macros should do it.
> * this has to be activated by TARGET-endian-ness != HOST-endian-ness
> ... it's not enough to look at the target.
I don't think so. If you do byte access (like we should do as soon as we access to 'external' structures), the host doesn't matter.
> ... anyway it will have to go on the TODO ;) ... other things to attack first.
Up to you!
Cheers,
Tristan.