Re: Difference between --oformat binary, and objcopy -O binary of --oformat elf32-i386

[linuxyne citadel <linuxyne at gmail dot com>]

Thanks Nick.

When you talk about deprecating --oformat use, do you also mean
deprecating OUTPUT_FORMAT in the linker scripts? The problem is seen
with both, as they seem to be aliases with --oformat overriding the
other one.

The errors, to which I referred in my previous email, are related to
the PIE addressing using GOT.

I did some more work on a sample code, and found that when using the
method (1), the linker does fill in proper values into the code which
calculates the address of the GOT (the calculated GOT address is
exactly the size of the binary).

       6:       e8 f5 0f 00 00          call   0x1000; call to the
thunk to get the retaddr = 0xb
       b:       05 61 10 00 00          add    $0x1061,%eax; eax has
the GOT = 0x106c

But when it is time to process the R_386_GOTOFF relocation included in
the object file,
the linker assumes GOT address as 0, which I think is a designed behaviour.

So, an instruction which dereferences a switch jump table, is seen as

      2a:       8b 94 02 1c 01 00 00    mov    0x11c(%edx,%eax,1),%edx

instead of the expected version of

      2a:       8b 94 02 b0 f0 ff ff    mov    -0xf50(%edx,%eax,1),%edx;,

where 0x11c is the start of the jump table, and 0x106c is the offset
of the non-existent GOT.


In conclusion,

the instruction such as this one, which has a R_386_GOTPC relocation
at address 0xc, was properly filled during linking, such that eax can
contain the address of the GOT as the correct value 0x106c,
       b:       05 61 10 00 00          add    $0x1061,%eax; eax has
the GOT = 0x106c

but when processing a R_386_GOTOFF relocation instruction such as below,
      2a:       8b 94 02 00 00 00 00    mov    0x0(%edx,%eax,1),%edx

the linker assumed the GOT address as 0, and emitted
      2a:       8b 94 02 1c 01 00 00    mov    0x11c(%edx,%eax,1),%edx

instead of
      2a:       8b 94 02 b0 f0 ff ff    mov    -0xf50(%edx,%eax,1),%edx

This looks like an inconsistency in handling R_386_GOTPC and
R_386_GOTOFF when OUTPUT_FORMAT or --oformat is set directly to
"binary".

Apologies for any inconvenience because of (at the least) my settings
on the gmail. I plan to setup mutt or thunderbird in some time.

Thanks,
linuxyne.


On 7/19/16, Nick Clifton <nickc@redhat.com> wrote:
> Hi linuxyne,
>
>> (1) --oformat binary
>> (2) --oformat elf32-i386 and then objcopy -O binary,
>>
>> the resulting code linked and stored within each resultant binary is
>> different from one another, even though both use the same .o file.
>>
>> An observation shows (2) creates correct binaries, but (1) does not.
>>
>> Do we know, beforehand, if this is an error on the part of the user
>> compiling the code,
>
> No - the compilation of the code is fine.
>
>> or if this is a designed
>
> It is not a designed behaviour, but...
>
>> or even an unsupported behaviour.
>
> ... it is basically unsupported.  Using the --oformat option of the
> linker is known to be problematic in lots of cases.  It is far better
> to use method (2), as this is much more likely to achieve the correct
> outcome.
>
> Possibly the use of --oformat in the linker should be deprecated,
> although there may be some situations where it does work.
>
> Cheers
>   Nick
>
>