mips64 : symbol DT_TEXTREL present in the shared object

[de...@codeplay.com]

Hi,
I'm experiencing a relocation issue with the mclinker for mips provided in Android.  I am testing the RenderScript back-end, bcc, to compile object files with the -O0 flag in the mips64 emulator. After that the renderscript runtime creates a shared library out of the generated object file, in my case saturation.o, with the following command:
/system/bin/ld.mc -shared -nostdlib /system/lib64/libcompiler_rt.so -mtriple=mips64el-none-linux-gnueabi --library-path=/system/vendor/lib64 --library-path=/system/lib64 -lRSDriver -lm -lc /data/data/com.example.android.basicrenderscript/code_cache/com.android.renderscript.cache/saturation.o -o /data/data/com.example.android.basicrenderscript/code_cache/com.android.renderscript.cache/librs.saturation.so
The shared object is created, but once the runtime attempts to load it, it raises the error:
Unable to open shared library (/data/data/com.example.android.basicrenderscript/code_cache/com.android.renderscript.cache/librs.saturation.so): dlopen failed: text relocations (DT_TEXTREL) found in 64-bit ELF file
Indeed, the shared object contains the symbol DT_TEXTREL in the dynamic section, and when passing the option --warn-shared-textrel a corresponding warning is raised by the mclinker as well. Debugging the linker I found out that the shared object is flagged with DT_TEXTREL due to the section .eh_frame being marked ALLOCATE but not WRITE, whereas this section is not present at all when the source is compiled with -O3. I also noticed that with the gnu linker this symbol does not appear, nor with the mclinker targeting aarch64. Oddly enough, the symbol is also generated by the mips32 mclinker, but the mips32 emulator nevertheless succeeds to load the library with no errors. This behaviour persists also when using the latest snapshot of the mclinker from upstream.

Unfortunately I was not able to create a small repro to pass using the NDK toolchains, because every time the produced objects exhibited the section .eh_frame marked both ALLOCATE and WRITE. But I am attaching the object file produced by bcc and used to create the shared library. Could you please provide any insights or let me know whether you require further info?

Kind regards,
Dean De Leo

[Simon Atanasyan]

Hi,

Thanks for the bug report. I am going to investigate the problem
in the next few days. My plan is to debug both mclinker and gnu
linkers to find out the difference. Is it possible to get self-contained
test case to reproduce the problem? Or at least RSDriver library binaries
to minimize initial setup of the debug environment.

--
Simon Atanasyan

[Dean De Leo]

Hi Simon,

thanks for looking into this. I have attached the libraries from my
environment.

Thanks,
Dean

Dean De Leo
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

[Rich Fuhler]

Hi Dean, there was a patch pushed to  AOSP for this problem. Perhaps it didn't make it into the NDK, as with the stat/fstat problem.  I'll check with our Android team manager (Raghu) when he returns from holiday.

-rich

--
You received this message because you are subscribed to the Google Groups "MCLinker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mclinker+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Atanasyan]

Rich:
I think you mean the following fix included in the Android NDK,
Revision 10e (May 2015), right?

https://developer.android.com/ndk/downloads/index.html
[[
Fixed Clang 3.5 for mips and mips64 to create a writable
.gcc_except_table section, thus matching GCC behavior. This change
allows you to avoid the following linker warning:

.../ld: warning: creating a DT_TEXTREL in a shared object
]]

Dean:
Do you use Revision 10e (or newer) version of NDK?

--
Simon Atanasyan

[Stephen Hines]

Is this in upstream? Andrew's NDK fork is now being replaced with the platform versions of everything. This means that we won't have any patches that weren't upstreamed.

Steve

[Dean De Leo]

Hi,

is this a patch for the linker or for the compiler?
In the former case, I have been testing this with both the linker
present in the NDK r10e and the master branch from
https://github.com/mclinker/mclinker/. Basically I am loading the object
and the libs from the emulator, invoking the linker in the host, and
finally moving the shared object artifact back onto the emulator.
Though the note from Simon refers to clang, do you mean this is an issue
that involves the compiler?

Thanks,
Dean

[Pete Chou]

I think it's for llvm.

https://android.googlesource.com/toolchain/llvm/+/48604b20a5daaa114c9cad67f1811c321ec0d947%5E%21/

Thanks,

Pete

[Simon Atanasyan]

Hi,

It looks like I caught the bug in the linker. It relates to handling R_MIPS_64 relocations against section symbols. Hope to provide a fix in a couple of days.

Regards,
Simon

[Dean De Leo]

Hi,

my apologies for this late reply, I had few issues with my computer till yesterday.
Thanks for pointing me out this patch.  There are indeed two distinct LLVM compiler toolchains related to the AOSP: the NDK and then <aosp>/external/llvm, used at least by the renderscript backend on the device and this is the one I am testing. The LLVM patch you referred belongs to the NDK, it seems it never went to LLVM upstream nor it is included in the LLVM part of the AOSP.
I applied it through cherry picking to the aosp/llvm this afternoon, and unfortunately it didn't resolve the issue. Reading the code it should set .eh_frame as writable, I gave a quick look with the debugger and it seemed that the section was properly flagged, but at the end the section in the final object was still read only. I'll inspect this issue more carefully tomorrow.

The note by Simon refers to the difference of behaviour between the GNU linker and the mclinker, at this point I'm confused whether this is a bug in the compiler or in the linker?

Thanks,
Dean

[Simon Atanasyan]

On Wed, Sep 9, 2015 at 8:52 PM, Dean De Leo <de...@codeplay.com> wrote:
> I applied it through cherry picking to the aosp/llvm this afternoon, and
> unfortunately it didn't resolve the issue. Reading the code it should set
> .eh_frame as writable, I gave a quick look with the debugger and it seemed
> that the section was properly flagged, but at the end the section in the
> final object was still read only. I'll inspect this issue more carefully
> tomorrow.

Could you please send new saturation.o with writable .eh_frame
section. I constructed such file by myself and MCLinker correctly
generated writable .eh_frame section in the output file.

> The note by Simon refers to the difference of behaviour between the GNU
> linker and the mclinker, at this point I'm confused whether this is a bug in
> the compiler or in the linker?

GNU linker successfully deals with read-only .eh_frame sections
because it tries to convert absolute FDE relocations into relative
ones and so it does not need to create dynamic relocations. It looks
like this functionality is missed in MCLinker. I asked Pete Chou about
that in the separate thread.

--
Simon Atanasyan

[Dean De Leo]

Hi Simon,

On 09/09/15 19:52, Simon Atanasyan wrote:
> Could you please send new saturation.o with writable .eh_frame
> section. I constructed such file by myself and MCLinker correctly
> generated writable .eh_frame section in the output file.

ok finally I was able to produce a writable section for the ".eh_frame"
by setting EHSectionFlags with the changes in the attachment, whereas
the patch reported above for the NDK marks LSDASection =
Ctx->getELFSection(".gcc_except_table") (I don't know what this section
refers to).
My problem was the compiler still producing an .eh_frame being marked
read only, as when applying the NDK patch the output object file was the
same as before. I confirm this resolves the text relocation issue in the
linker.

Thanks,
Dean