什么会使 Android ARM .text 段(带汇编程序)不可共享?
What would make an Android ARM .text segment (with assembler) unshareable?
我正在尝试为我的 Android phone 编译 Beebdroid(以修复蓝牙键盘问题)。我遇到了链接器的问题,抱怨文本段不可共享:
arm-linux-androideabi/bin/ld: warning: shared library text segment is not shareable
我只是对segments这个原理比较熟悉,没遇到过这个。我看到 -fPIC
已经在 makefile 的 x86 分支上,ARM 似乎不太可能需要它,因为它具有简单的 PC 相对寻址,但我将它添加到 ARM 标志中无济于事,所以我假设它不是 C 代码。
这让我假设是汇编代码触发了错误。
https://github.com/littlefluffytoys/Beebdroid/blob/master/app/src/main/jni/6502asm_arm.S
它确实在汇编文件的前面说了 .text
,但我在 infocentre.arm.com 查看了 clang 汇编程序指南,我唯一可以替换的 executable 段是 'init' 和 'fini',这两个看起来都不是个好主意。
汇编程序是否在程序集中发现了一些狡猾的代码,并将文本段标记为不可共享,以使链接器崩溃?没有任何警告。
有一个由 6502 个操作码索引的查找 table 以查找实现例程:
@ Get the ASM function. If this doesnt exist, fall back to C version.
adr r1, fns_asm // previously ldr r1, =fns_asm
ldr r2, [ r1, r0, lsl #2]
cmp r2, #0
beq use_c_fn
@ Call assembly function
blx r2
b done_call
我已经将 ldr
更改为 adr
,并将函数移动到更靠近 table 的位置,因此它在范围内,我希望必须获得汇编程序使 table 相对,并在我跳转之前添加 PC,但我有点希望在我开始尝试解决细节问题之前获得成功的编译。
有很多宏,但我能看到的唯一指令是 .text
、.global exec6502
和一个 .ltorg
、none,它们看起来应该如此造成问题。
它是被 table 本身窒息了吗?我是否必须从每个例程标签中减去另一个标签,以便汇编器理解它们是相对的?好像……有点高级
是否需要我提供 -fPIC 的汇编版本?
感谢您的指点。
编辑:我刚刚注意到还有一些 ldr Rx,=
指令 - 两个与别处定义的标签相关,一个(我认为)与绝对地址 40000 相关。看来我需要问一下如何获得以 PIC 兼容的方式来自汇编器的 C 标签!
编辑 2:我想我可以将函数指针字段添加到 CPU 寄存器结构,我将把它传递给 r0 中的代码(而不是使用 acpu)并保留在 r4 中作为当前代码是。
问题是 ldr r1, =c_symbol
指令和 .word assembler_label
个条目的 table 的组合。
将一些代码移近 table 就足够了,这样我就可以用 adr r1, fns_asm
替换 ldr r1, =fns_asm
和(如@Artlessnoise 所说)search/replace table 到计算的偏移量:
fns_asm:
.word 0 // 0x00 BRK
.word 0 - fns_asm + opasm_ora_indzx // 0x01 ORA (,x)
.word 0 - fns_asm + opasm_undef
...and so on
因为原来是原始符号让链接器不满意。我本来想把它当作 .word 0 + opasm_ora_indzx
来使用,然后在 运行 时做减法,但这行得通:
@ Get the ASM function. If this doesnt exist, fall back to C version.
adr r1, fns_asm
ldr r2, [ r1, r0, lsl #2] // = fns_asm[ op * 4 ]
cmp r2, #0
beq use_c_fn
@ Call assembly function
add r2, r2, r1 // 0 - fns_asm + asy_func + fns_asm
blx r2 // Call assembly function
b done_call
我应该整理 table,但是 0 - x + y 废话是所有 256 个条目中最简单的搜索替换。
现在正在为 ARM 编译和 运行ning,我可以尝试修复我真正关心的主要应用程序的部分。
我正在尝试为我的 Android phone 编译 Beebdroid(以修复蓝牙键盘问题)。我遇到了链接器的问题,抱怨文本段不可共享:
arm-linux-androideabi/bin/ld: warning: shared library text segment is not shareable
我只是对segments这个原理比较熟悉,没遇到过这个。我看到 -fPIC
已经在 makefile 的 x86 分支上,ARM 似乎不太可能需要它,因为它具有简单的 PC 相对寻址,但我将它添加到 ARM 标志中无济于事,所以我假设它不是 C 代码。
这让我假设是汇编代码触发了错误。
https://github.com/littlefluffytoys/Beebdroid/blob/master/app/src/main/jni/6502asm_arm.S
它确实在汇编文件的前面说了 .text
,但我在 infocentre.arm.com 查看了 clang 汇编程序指南,我唯一可以替换的 executable 段是 'init' 和 'fini',这两个看起来都不是个好主意。
汇编程序是否在程序集中发现了一些狡猾的代码,并将文本段标记为不可共享,以使链接器崩溃?没有任何警告。
有一个由 6502 个操作码索引的查找 table 以查找实现例程:
@ Get the ASM function. If this doesnt exist, fall back to C version.
adr r1, fns_asm // previously ldr r1, =fns_asm
ldr r2, [ r1, r0, lsl #2]
cmp r2, #0
beq use_c_fn
@ Call assembly function
blx r2
b done_call
我已经将 ldr
更改为 adr
,并将函数移动到更靠近 table 的位置,因此它在范围内,我希望必须获得汇编程序使 table 相对,并在我跳转之前添加 PC,但我有点希望在我开始尝试解决细节问题之前获得成功的编译。
有很多宏,但我能看到的唯一指令是 .text
、.global exec6502
和一个 .ltorg
、none,它们看起来应该如此造成问题。
它是被 table 本身窒息了吗?我是否必须从每个例程标签中减去另一个标签,以便汇编器理解它们是相对的?好像……有点高级
是否需要我提供 -fPIC 的汇编版本?
感谢您的指点。
编辑:我刚刚注意到还有一些 ldr Rx,=
指令 - 两个与别处定义的标签相关,一个(我认为)与绝对地址 40000 相关。看来我需要问一下如何获得以 PIC 兼容的方式来自汇编器的 C 标签!
编辑 2:我想我可以将函数指针字段添加到 CPU 寄存器结构,我将把它传递给 r0 中的代码(而不是使用 acpu)并保留在 r4 中作为当前代码是。
问题是 ldr r1, =c_symbol
指令和 .word assembler_label
个条目的 table 的组合。
将一些代码移近 table 就足够了,这样我就可以用 adr r1, fns_asm
替换 ldr r1, =fns_asm
和(如@Artlessnoise 所说)search/replace table 到计算的偏移量:
fns_asm:
.word 0 // 0x00 BRK
.word 0 - fns_asm + opasm_ora_indzx // 0x01 ORA (,x)
.word 0 - fns_asm + opasm_undef
...and so on
因为原来是原始符号让链接器不满意。我本来想把它当作 .word 0 + opasm_ora_indzx
来使用,然后在 运行 时做减法,但这行得通:
@ Get the ASM function. If this doesnt exist, fall back to C version.
adr r1, fns_asm
ldr r2, [ r1, r0, lsl #2] // = fns_asm[ op * 4 ]
cmp r2, #0
beq use_c_fn
@ Call assembly function
add r2, r2, r1 // 0 - fns_asm + asy_func + fns_asm
blx r2 // Call assembly function
b done_call
我应该整理 table,但是 0 - x + y 废话是所有 256 个条目中最简单的搜索替换。
现在正在为 ARM 编译和 运行ning,我可以尝试修复我真正关心的主要应用程序的部分。