Hi Dave,
On 6/27/19 3:38 PM, Dave Martin wrote:
> On Thu, Jun 27, 2019 at 12:59:07PM +0100, Vincenzo Frascino wrote:
>> On 6/27/19 12:27 PM, Dave Martin wrote:
>>> On Thu, Jun 27, 2019 at 11:57:36AM +0100, Vincenzo Frascino wrote:
>
> [...]
>
>>>> Disassembly of section .text:
>>>> 0000000000000000 show_it:
>>>> 0: e8 03 1f aa mov x8, xzr
>>>> 4: 09 68 68 38 ldrb w9, [x0, x8]
>>>> 8: 08 05 00 91 add x8, x8, #1
>>>> c: c9 ff ff 34 cbz w9, #-8 <show_it+0x4>
>>>> 10: 02 05 00 51 sub w2, w8, #1
>>>> 14: e1 03 00 aa mov x1, x0
>>>> 18: 08 08 80 d2 mov x8, #64
>>>> 1c: 01 00 00 d4 svc #0
>>>> 20: c0 03 5f d6 ret
>>>>
>>>> Commands used:
>>>>
>>>> $ clang -target aarch64-linux-gnueabi main.c -O -c -o main.clang.<x>.o
>>>> $ llvm-objdump -d main.clang.<x>.o
>>>
>>> Actually, I'm not sure this is comparable with the reproducer I quoted
>>> in my last reply.
>>>
>>
>> As explained in my previous email, this is the only case that can realistically
>> happen. vDSO has no dependency on any other library (i.e. libgcc you were
>> mentioning) and we are referring to the fallbacks which fall in this category.
>
> Outlining could also introduce a local function call where none exists
> explicitly in the program IIUC.
>
> My point is that the interaction between asm reg vars and machine-level
> procedure calls is at best ill-defined, and it is largely up to the
> compiler when to introduce such a call, even without LTO etc.
>
> So we should not be surprised to see variations in behaviour depending
> on compiler, compiler version and compiler flags.
>
I tested 10 version of the compiler and a part gcc-5.1 that triggers the issue
in a specific case and not in the vdso library, I could not find evidence of the
problem.
>>> The compiler can see the definition of strlen and fully inlines it.
>>> I only ever saw the problem when the compiler emits an out-of-line
>>> implicit function call.
>>>> What does clang do with my example on 32-bit?
>>
>> When clang is selected compat vDSOs are currently disabled on arm64, will be
>> introduced with a future patch series.
>>
>> Anyway since I am curious as well, this is what happens with your example with
>> clang.8 target=arm-linux-gnueabihf:
>>
>> dave-code.clang.8.o: file format ELF32-arm-little
>>
>> Disassembly of section .text:
>> 0000000000000000 foo:
>> 0: 00 00 00 ef svc #0
>> 4: 1e ff 2f e1 bx lr
>>
>> 0000000000000008 bar:
>> 8: 10 4c 2d e9 push {r4, r10, r11, lr}
>> c: 08 b0 8d e2 add r11, sp, #8
>> 10: 00 40 a0 e1 mov r4, r0
>> 14: fe ff ff eb bl #-8 <bar+0xc>
>> 18: 00 10 a0 e1 mov r1, r0
>> 1c: 04 00 a0 e1 mov r0, r4
>> 20: 00 00 00 ef svc #0
>> 24: 10 8c bd e8 pop {r4, r10, r11, pc}
>
>> Compiled with -O2, -O3, -Os never inlines.
>
> Looks sane, and is the behaviour we want.
>
>> Same thing happens for aarch64-linux-gnueabi:
>>
>> dave-code.clang.8.o: file format ELF64-aarch64-little
>>
>> Disassembly of section .text:
>> 0000000000000000 foo:
>> 0: e0 03 00 2a mov w0, w0
>> 4: e1 03 01 2a mov w1, w1
>> 8: 01 00 00 d4 svc #0
>> c: c0 03 5f d6 ret
>>
>> 0000000000000010 bar:
>> 10: 01 0c c1 1a sdiv w1, w0, w1
>> 14: e0 03 00 2a mov w0, w0
>> 18: 01 00 00 d4 svc #0
>> 1c: c0 03 5f d6 ret
>
> Curious, clang seems to be inserting some seemingly redundant moves
> of its own here, though this shouldn't break anything.
>
> I suspect that clang might require an X-reg holding an int to have its
> top 32 bits zeroed for passing to an asm, whereas GCC does not. I think
> this comes under "we should not be surprised to see variations".
>
> GCC 9 does this instead:
>
> 0000000000000000 <foo>:
> 0: d4000001 svc #0x0
> 4: d65f03c0 ret
>
> 0000000000000008 <bar>:
> 8: 1ac10c01 sdiv w1, w0, w1
> c: d4000001 svc #0x0
> 10: d65f03c0 ret
>
>
>> Based on this I think we can conclude our investigation.
>
> So we use non-reg vars and use the asm clobber list and explicit moves
> to get things into / out of the right registers?
>
Since I managed to provide enough evidence, based on the behavior of various
versions of the compilers, that the library as it stands is consistent and does
not suffer any of the issues you reported I think I will keep my code as is at
least for this release, I will revisit it in future if something happens.
If you manage to prove that my library as it stands (no code additions or source
modifications) has the issues you mentioned based on some version of the
compiler, this changes everything.
Happy to hear from you.
> Cheers
> ---Dave
>
--
Regards,
Vincenzo
