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.
... IMPORT foo ... LDR r0,=foo or DCD foo ...
I'm not sure I know exactly what you mean by TEXTREL. I'm guessing it's a non-PC-relative relocation from a .text (or RO) section. (Such a relocation would have to be performed at load time (by a dynamic linker) for a shared object.)Unlike the compiler, the assembler has little or no choice about the relocations it produces. If you have something like ... IMPORT foo ... LDR r0,=foo or DCD foo ...then the assembler has to produce a non-PC-relative relocation.When you tell armasm '--apcs /fpic' you are promising that it is appropriate to mark the RO sections object code as position-independent. This is different from building C or C++ code where '--apcs /fpic' is telling the compiler to make sure the RO sections object code are position-independent.The assembler can't add the code needed to use a PC-relative relocation, but the compiler can.I don't think there's any solution besides finding out what asm constructs are producing the unwanted relocations and changing them. (Using asm macros might make it easier to maintain.)
Thank you for the reply.I had removed all the IMPORTS from my assembly but still TEXTREL is coming in library.I am building handwritten assembly with armcc only(not sure whether it uses armasm internally).My assembly functions are in .c files in following fashion:CODE:__asm void func1(){}So can you tell me what else may be reason, for generation of TEXTREL in library.
You're using what's known as "embedded assembly". What you write inside the embedded asm functions has pretty much the same rules as a .s file, but armcc will generate some EXPORT/PROC/ENDP directives for you and some IMPORT directives if you're using __cpp(...).It's not using the IMPORT directive per se that is generating the relocation; it's what you do with the imported symbol (DCD or LDR rx,= in my example above). If know the symbols being used by the unwanted relocations and can post the embedded asm lines that mention them; we might be able to suggest what you could do instead.
void foo {__asm { ...}
__asm void foo() { ...}
extern int table[] = { 1, 2, 3 };__asm void *foo() { import table /* should not really be needed, but is */ ldr r0, lbl add r0, r0, pc bx lrlbl dcd table - .}
extern int table[] = { 1, 2, 3};int foo_c(int i) { return table[i]; }
__asm int foo_asm() { ldr r1, dlblulbl add r1, r1, pc ldr r0,[r1,r0,lsl #2] bx lr aligndlbl dcd __cpp(table) - ulbl - 8}
__asm int foo_asm_non_PI() { ldr r1, dlbl ldr r0,[r1,r0,lsl #2] bx lr aligndlbl dcd __cpp(table)}
__asm int foo_asm_non_PI2() { ldr r1, =__cpp(table) ldr r0,[r1,r0,lsl #2] bx lr}
extern short int table_1[33];int foo(int i){ return table_1[i];}__asm int foo_asm(int i){ LDR r1, dlblulblADD r1, r1, pcLDR r0, [r1,r0,lsl #2]bx lraligndlbl DCD __cpp(table_1) - ulbl - 8 RELOC 96, table_1 //if this is used then only TEXTREL is not generated}
; generated by ARM NEON C/C++ Compiler, RVCT4.0 [Build 771]; commandline armcc [--arm -c -S --gnu --no_hide_all --library_interface=aeabi_glibc -oobj/test.tmp.s --cpu=Cortex-A8 --fpu=VFPv3 --apcs=/interwork//fpic --no_unaligned_access -O3 -Otime --vectorize --enum_is_int --wchar32 obj/test.tmp.c] ARM REQUIRE8 PRESERVE8 AREA ||.text||, CODE, READONLY, ALIGN=2||foo|| PROC LDR r1,|L0.20| LDR r1,[pc,r1] ADD r0,r1,r0,LSL #1 LDRSH r0,[r0,#0] BX lr ENDP|L0.20| DCD 0x00000008 ;Line 18 RELOC 96, table_1 ;Line 19 AREA ||.arm_vfe_header||, DATA, READONLY, NOALLOC, ALIGN=2 DCD 0x00000000;*** Start embedded assembler *** #line 1 "obj/test.tmp.c" AREA ||.emb_text||, CODE, READONLY ARM EXPORT |foo_asm| [DYNAMIC] IMPORT |table_1| [DYNAMIC]#line 10|foo_asm| PROC#line 11LDR r1, dlblulblADD r1, r1, pcLDR r0, [r1,r0,lsl #2]bx lraligndlblDCD |table_1| - ulbl - 8 ;Line 44ENDP;*** End embedded assembler *** EXPORT ||foo|| [CODE,DYNAMIC] IMPORT ||Lib$$Request$$armlib|| [CODE,WEAK] IMPORT table_1 [DATA,DYNAMIC] ATTR FILESCOPE ATTR SETVALUE Tag_ABI_PCS_wchar_t,4 ATTR SETVALUE Tag_ABI_enum_size,2 ATTR SETVALUE Tag_ABI_optimization_goals,2 ATTR SETSTRING Tag_conformance,"2.06" ATTR SETVALUE AV,18,1 ASSERT {ENDIAN} = "little" ASSERT {INTER} = {TRUE} ASSERT {ROPI} = {TRUE} ASSERT {RWPI} = {FALSE} ASSERT {IEEE_FULL} = {FALSE} ASSERT {IEEE_PART} = {FALSE} ASSERT {IEEE_JAVA} = {FALSE} END
I am also facing similar relocation issue. i am facing issue in normal c code where assembly has been disabled. Code is compiled using RVCT4.0 build 771. I tried with all possible options like --apcs /fpic, --apcs=/ropi --lower_ropi etc but it has no effect.Is there any utility or method using which we can identify, the parts of code responsible for these?
I'm not sure I understand the problem correctly. Can you explain what symptoms and/or error messages you are seeing (with examples if possible)?Understanding relocation problems usually involves dumping the images and/or objects with 'fromelf -yr ...' or 'readelf -Dr ...'. It can be a bit of a chore to go from a dynamic relocation in an image back to the object file it came from -- in the worst case you'll need the link map, too.
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?
fromelf -cyr foo.so > foo.so.dump
objdump -dR foo.so > foo.so.dump