[llvm] r205076 - Completely rewrite ELFObjectWriter::RecordRelocation.

[Artyom Skrobov]

Hello Rafael,

There is one more problem we’ve encountered since r205076, and r205416
didn’t fix it.
(It took us quite some time to attribute our problem to that commit.)

The following code:

target triple = "thumbv7-none-eabi"
define internal void @fn()
{
    ret void
}
@ptr = global i8* bitcast (void ()* @fn to i8*)

-- used to produce, for ptr, a relocation of the type R_ARM_ABS32, relative
to symbol ‘fn’, defined at offset 1 (the lowest bit indicates this as a
Thumb function, the function body beginning at offset 0).
The pre-relocation value of ptr was always set to 0.

Since r205076, it produces a relocation of the type R_ARM_ABS32, relative to
the anonymous symbol pointing at the beginning of section '.text', i.e.
offset 0.
Had fn not started at the beginning of the section, its actual offset would
be stored in the (pre-relocation) value of ptr, with the LSB cleared, as in
this case.

After linking, naturally ptr gets the LSB set in the former case (before
r205076), but cleared in the current state.
Therefore, using ptr for an indirect jump now switches the CPU to ARM mode,
and crashes.

This test case is reduced from some actual C++ code defining a VTable.

We haven’t yet looked at the code that may be causing this, but maybe you
know off the top of your head what the problem might be?


> Thx! \o/
>
>
> On Wed, Apr 2, 2014 at 2:22 PM, Rafael Espíndola <rafael.espindola at
gmail.com
>> wrote:
>
>> r205416
>>
>> On 2 April 2014 03:30, Manuel Klimek <klimek at google.com> wrote:
>> > That indeed fixes it. Thanks!
>> >
>> >
>> > On Tue, Apr 1, 2014 at 11:20 PM, Rafael Espíndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>
>> >> On 1 April 2014 16:15, Manuel Klimek <klimek at google.com> wrote:
>> >> > On Tue, Apr 1, 2014 at 9:59 PM, Rafael Espíndola
>> >> > <rafael.espindola at gmail.com> wrote:
>> >> >>
>> >> >> OK, I am pretty sure I found a bug in gold, it works with bfd ld. I
>> >> >> should have a bug number and a workaround soon.
>> >> >
>> >> >
>> >> > Awesome. Thanks!
>> >>
>> >>
>> >> Can you test the attached patch?
>> >>
>> >> Cheers,
>> >> Rafael
>> >
>> >
>>