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

[Artyom Skrobov]

Yes, this fixed it for us.

Thanks a lot!


-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] 
Sent: 11 April 2014 20:25
To: Artyom Skrobov
Cc: llvm-commits; Manuel Klimek
Subject: Re: [llvm] r205076 - Completely rewrite ELFObjectWriter::RecordRelocation.

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/
>>
>>