• Locked Locked
  • Replies 17 replies
  • Subscribers 119 subscribers
  • Views 15941 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem in generating position independent code with out TEXTREL

Darisi V SATISH BABU
Note: This was originally posted on 12th August 2010 at http://forums.arm.com

Hi Experts,

Issue:Not able to remove TEXTREL from our static library generated with --apcs /fpic option using armcc(RVCT 4.0 build 771  tool chain)

Description:
    We compiled our codebase(some modules with handwritten assembly) using armcc(RVCT 4.0 build 771  tool chain) to get static libraries, and then these are used by gstreamer module which further compiles using the above generated libraries with wrappers using GCC tool chain and creates shared objects(.so).

Even though we use equivalent --apcs /fpic compile time option during static library creation to remove position independent code, the TEXTREL are not going from library.
When we disable the (handwritten assembly) in the above mentioned codebase, TEXTRELs go away.
As there are lot of handwritten ARM assembly functions,its difficult to enable one by one and compile and check. :unsure:

So,Experts please throw some light on this issue.


Thanks In Advance,
satish
Parents
  • Arm Employee Badge
    Note: This was originally posted on 18th August 2010 at http://forums.arm.com

    I tried executing readelf -d ... ,
    This clearly showed there is a TEXTREL
    ...
    0x00000016 (TEXTREL)      0x0
    ...
    how can we link this to a paricular part of code?


    One thing to try, if you're using armlink, is adding '--diag_warning=6408,6409' to enable warnings when a non-PI object file is used when linking with --fpic.  Unfortunately it will warn even if there are no offending relocations.  [I've requested an enhancement to warn when DT_TEXTREL is set and give the object file info.]

    [I don't have a precise example for this next bit.]
    To find the offending relocation by hand, dump the code and dynamic relocations of the image:
    fromelf -cyr foo.so > foo.so.dump
    or
    objdump -dR foo.so > foo.so.dump
    Now find the dynamic relocations whose offsets are in read-only segments.  Use the offset to find the code being relocated.  Look above that location for the nearest symbol.  Hopefully this will be a unique function name which will lead you to the source.  Otherwise you might need to create a link map and use it to find which object file was placed at the offset.

    If the reason for the relocation is not clear from the source, post the relevant parts of the image dump (relocation info and code around the offset) and source.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 18th August 2010 at http://forums.arm.com

    I tried executing readelf -d ... ,
    This clearly showed there is a TEXTREL
    ...
    0x00000016 (TEXTREL)      0x0
    ...
    how can we link this to a paricular part of code?


    One thing to try, if you're using armlink, is adding '--diag_warning=6408,6409' to enable warnings when a non-PI object file is used when linking with --fpic.  Unfortunately it will warn even if there are no offending relocations.  [I've requested an enhancement to warn when DT_TEXTREL is set and give the object file info.]

    [I don't have a precise example for this next bit.]
    To find the offending relocation by hand, dump the code and dynamic relocations of the image:
    fromelf -cyr foo.so > foo.so.dump
    or
    objdump -dR foo.so > foo.so.dump
    Now find the dynamic relocations whose offsets are in read-only segments.  Use the offset to find the code being relocated.  Look above that location for the nearest symbol.  Hopefully this will be a unique function name which will lead you to the source.  Otherwise you might need to create a link map and use it to find which object file was placed at the offset.

    If the reason for the relocation is not clear from the source, post the relevant parts of the image dump (relocation info and code around the offset) and source.
Children
No data