ASH: why ash_ptr_to_globals_misc is declared as const pointer

[Mike Frysinger]

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>