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

Rafael Espíndola rafael.espindola at gmail.com
Fri Apr 11 12:25:11 PDT 2014


Should be fixed in r206047.

Sorry about that.

On 11 April 2014 17:15, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> 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
>>> >
>>> >
>>>
>
>
>




More information about the llvm-commits mailing list