[PATCH 1/3] aarch64: Clean up _dl_runtime_resolve

[Szabolcs Nagy]

On 02/08/18 18:04, Richard Henderson wrote:
> On 08/02/2018 12:03 PM, Szabolcs Nagy wrote:
>> On 01/08/18 23:23, rth@twiddle.net wrote:
>>> From: Richard Henderson <richard.henderson@linaro.org>
>>>
>>>  Â Â Â Â * sysdeps/aarch64/dl-trampoline.S (_dl_runtime_resolve):
>>>  Â Â Â Â Do not record unwind info for arguments; this is unneeded;
>>>  Â Â Â Â do not save x9 just to have a register to pair with x8;
>>>  Â Â Â Â properly include the 16 bytes of PLT stack into the unwind;
>>>  Â Â Â Â create a frame pointer with the spare stack slot;
>>>  Â Â Â Â rearrange the exit to only adjust the stack once.
>>
>> i thought the cfi annotations were needed for all registers
>> in case the debugger wants to investigate register content
>> across a _dl_runtime_resolve frame (possibly several frames
>> up in the call stack),
> 
> However that's typically for the call-saved registers, where the compiler might
> save data in that register across the call.  These are not call-saved
> registers.  They are argument registers.  There will not be any debug info that
> refers to them.
> 
>> this may not be a common use case though
>> and i don't know what's the convention in glibc asm, the compiler
>> seems to emit annotation for all spilled registers with -g.
> 
> Sure, because the compiler is spilling call-saved registers.
> The others it just clobbers with no annotation.
> 
>>> -Â Â Â  cfi_startproc
>>>  Â Â Â Â Â  .align 2
>>>  Â  _dl_runtime_resolve:
>>>  Â Â Â Â Â  /* AArch64 we get called with:
>>> @@ -41,46 +40,24 @@ _dl_runtime_resolve:
>>>  Â Â Â Â Â Â Â Â  [sp, #8]Â Â Â  lr
>>>  Â Â Â Â Â Â Â Â  [sp, #0]Â Â Â  &PLTGOT[n]
>>>  Â Â Â Â Â Â  */
>>> -
>>> +Â Â Â  cfi_startproc
>>
>> is there a problem keeping it at its original place above?
>> the tlsdesc asm has cfi_startproc at the same place.
> 
> It could stay where it is, but I thought it clearer to place the following two
> annotations immediately adjacent (because it's state incoming, not anything we
> are doing here, and should not be separated from the start).  Further, to place
> all of the annotations immediately after the comment that describes why.
> 

i see, then this patch is OK to commit, thanks.