Conversion of absolute FDE relocations into relative ones

[Simon Atanasyan]

Hi Pete,

GNU linker (bfd) in case of linking shared library tries to convert
absolute FDE relocations into relative ones. As a reference you can
take a look at _bfd_elf_parse_eh_frame routine from binutils. Does
MCLinker perform the same conversion? If it does not, do you plan to
implement this functionality?

My question is inspired by the bugs recently reported against MCLinker
MIPS. The problem is that if an object file contains the .eh_frame
section with absolute R_MIPS_32 relocations these relocations are
converted into dynamic ones. But Android does not like dynamic
relocations which modify read-only section.

Regards,
Simon Atanasyan

[Pete Chou]

Hi Simon,

Thanks for your information. Will study this interesting feature.

Thanks,

Pete

[Diana Chen]

Hi Simon, 

Sorry if I misunderstood anything. When building shared objects, MCLinker converts R_MIPS_32 relocations into R_MIPS_REL32 if required. Do you expect that it should not do this conversion if R_MIPS_32 against FDE? I'm still studying bfd code. It looks like bfd will static resolve this kind of relocations. Is it? And also, It seems that .eh_frame is a writable section. How does Android complain about the dynamic relocations in eh_frame?

Thank you!

-Diana

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

[Diana Chen]

Ah.. I think I got your point. bfd handles ABS relocations against eh_frame as REL relocations. Hence it won't produce dynamic relocations in the output. Will see how to add this feature into mcld. 

Thanks,

-Diana

[Simon Atanasyan]

Hi Diana,

You absolutely right.

In fact, the priority of this feature is not high now because it looks
like writable .eh_frame sections solves the initial problem.

Regards,
Simon

--
Simon Atanasyan

[Dean De Leo]

Hi,

thank you for looking into this issue. Still what's the general
consensus about this feature?
I'm looking whether the patch for making the section .eh_frame writable,
mentioned in the previous discussion, should be pushed to the llvm
project in AOSP, but if the relocations will be handled by the linker,
then this patch will not be necessary anymore.

Kind regards,
Dean De Leo

[Diana Chen]

Hi, we are planning to add this feature but not sure when. I'm wondering that do you have any schedule concern of it?

Thanks,

Diana

[Dean De Leo]

Hi Diana,

I made a merge request for the available patch to LLVM upstream, http://reviews.llvm.org/D13104, reviewers raised some fair points and do not seem inclined to consider this workaround.

Though it is not still clear to me whether this is a bug in the compiler or the linker? My understanding is, when asking for PIC, there should be no absolute relocations in the code, nor in the section .eh_frame, so it is the compiler that should emit relative references in the first place. This means there is a bug in the compiler. What you are discussing is some kind of fallback feature that the gnu/bfd linker exhibits, with the ability to transform absolute relocations to relative addresses when linking pic & read only sections. Is this correct? Or can you please clarify this point?

Regarding a schedule, I am testing the renderscript debugger in android mips and I would like to have a fix upstream for this issue, as it does not allow to load applications built for some reason with the .eh_frame section. Do you have a rough timeline for this feature?

Thanks,
Dean

--

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.

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

[Stephen Hines]

On Thu, Sep 24, 2015 at 4:38 AM, Dean De Leo <de...@codeplay.com> wrote:

Hi Diana,

I made a merge request for the available patch to LLVM upstream, http://reviews.llvm.org/D13104, reviewers raised some fair points and do not seem inclined to consider this workaround.

Though it is not still clear to me whether this is a bug in the compiler or the linker? My understanding is, when asking for PIC, there should be no absolute relocations in the code, nor in the section .eh_frame, so it is the compiler that should emit relative references in the first place. This means there is a bug in the compiler. What you are discussing is some kind of fallback feature that the gnu/bfd linker exhibits, with the ability to transform absolute relocations to relative addresses when linking pic & read only sections. Is this correct? Or can you please clarify this point?

Regarding a schedule, I am testing the renderscript debugger in android mips and I would like to have a fix upstream for this issue, as it does not allow to load applications built for some reason with the .eh_frame section. Do you have a rough timeline for this feature?

A fix for this issue would be greatly appreciated, since it would unblock MIPS RenderScript debugging for Android.

Thanks,

Steve

[Diana Chen]

On Fri, Sep 25, 2015 at 12:27 AM Stephen Hines <srh...@google.com> wrote:

On Thu, Sep 24, 2015 at 4:38 AM, Dean De Leo <de...@codeplay.com> wrote:

Hi Diana,

I made a merge request for the available patch to LLVM upstream, http://reviews.llvm.org/D13104, reviewers raised some fair points and do not seem inclined to consider this workaround.

Though it is not still clear to me whether this is a bug in the compiler or the linker? My understanding is, when asking for PIC, there should be no absolute relocations in the code, nor in the section .eh_frame, so it is the compiler that should emit relative references in the first place. This means there is a bug in the compiler. What you are discussing is some kind of fallback feature that the gnu/bfd linker exhibits, with the ability to transform absolute relocations to relative addresses when linking pic & read only sections. Is this correct? Or can you please clarify this point?

Agree with you. I think compiler should generate Relative type relocations for PIC code  instead of Absolute relocations. As we can see for X86 and AArch64, gcc generates Relative relocations in eh_frame, and hence won't cause any problem. While according to following discussion in http://reviews.llvm.org/D13104, it seems that generating relative relocations for Mips will cause other problem in bfd...

I'm looking at this feature in bfd and hope to add it to MCLinker in a month.

 -Diana