ASH: why ash_ptr_to_globals_misc is declared as const pointer
Mike Frysinger
vapier at gentoo.org
Fri Jan 19 23:32:02 UTC 2018
On 18 Jan 2018 13:48, Yunlian Jiang wrote:
> I tried to build busybox with clang and use it to create recovery image
> for ChromeOS.
> It fails to recover an arm based ChromeBook.
is it that busybox is crashing ? is clang/lld placing this pointer in const
memory (even though we have section(".data")) ? or is it generating an abort
when it reaches what it thinks is an undefined situation (like trying to write
to a const memory location in INIT_G_var()) ?
> I digged a little bit.
> Below patch makes it work.
your patch only changed two places ... presumably if this global ptr trickery
isn't working here, it doesn't work in any of them.
> My question is.
> the ash_ptr_to_globals_misc, ash_ptr_to_globals_memstack
> and ash_ptr_to_globals_var
> are defined in ash_ptr_hack.c as normal pointers. But in ash.c, they are
> declared as const
> pointers. What is the benefit of doing that?
the pointer itself is the thing that is const, not the memory it points to.
this lets the compiler optimize the loads by generating relocations via the
pointer ... there's the fixup at the initial load time, but after that, it's
just offsets to a constant memory location. but removing the const markings,
the compiler has to reload the pointer everytime.
you can check this yourself. this is the delta from removing the const:
54604 1222 488 56314 dbfa busybox.const
54964 1222 488 56674 dd62 busybox.no.const
+360 +360
and an example from the disassembly.
const/0000000000000000 <raise_exception>:
0: 48 83 ec 08 sub $0x8,%rsp
4: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # b <raise_exception+0xb>
7: R_X86_64_PC32 ash_ptr_to_globals_misc-0x4
b: 8b 50 38 mov 0x38(%rax),%edx
e: ff c2 inc %edx
10: 89 50 38 mov %edx,0x38(%rax)
13: 40 88 78 3f mov %dil,0x3f(%rax)
17: 48 8b 78 30 mov 0x30(%rax),%rdi
1b: be 01 00 00 00 mov $0x1,%esi
20: e8 00 00 00 00 callq 25 <raise_exception+0x25>
21: R_X86_64_PC32 __longjmp_chk-0x4
no.const/0000000000000000 <raise_exception>:
0: 48 83 ec 08 sub $0x8,%rsp
4: 48 8b 15 00 00 00 00 mov 0x0(%rip),%rdx # b <raise_exception+0xb>
7: R_X86_64_PC32 ash_ptr_to_globals_misc-0x4
b: 8b 42 38 mov 0x38(%rdx),%eax
e: ff c0 inc %eax
10: 89 42 38 mov %eax,0x38(%rdx)
>>> extra load <<<
> 13: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 1a <raise_exception+0x1a>
> 16: R_X86_64_PC32 ash_ptr_to_globals_misc-0x4
> 1a: be 01 00 00 00 mov $0x1,%esi
1f: 40 88 78 3f mov %dil,0x3f(%rax)
23: 48 8b 78 30 mov 0x30(%rax),%rdi
27: e8 00 00 00 00 callq 2c <raise_exception+0x2c>
28: R_X86_64_PC32 __longjmp_chk-0x4
would be nice if we documented all the little tricks we used somewhere.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20180119/9596198e/attachment.asc>
More information about the busybox
mailing list