arm64 vdso might miss .eh_frame

arm64 vdso might miss .eh_frame

[Szabolcs Nagy]

On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
by default since gcc-8, so now the de facto platform ABI is to allow
unwinding from async signal handlers.

However on bare metal targets (aarch64-none-elf), and on old gcc,
async and sync unwind tables are not enabled by default to avoid
runtime memory costs.

This means if linux is built with a baremetal toolchain the vdso.so
may not have unwind tables which breaks our (undocumented) platform
ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
explicitly to the vgettimeofday.o cflags would be nice (the other
objects in the vdso seem to be asm).

There was also a report that android clang built linux vdso.so lacks
.eh_frame completely, that may be a missing --eh-frame-hdr or different
platform ABI on android, Tamas on cc may be able to verify this.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Will Deacon]

On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
> by default since gcc-8, so now the de facto platform ABI is to allow
> unwinding from async signal handlers.
> 
> However on bare metal targets (aarch64-none-elf), and on old gcc,
> async and sync unwind tables are not enabled by default to avoid
> runtime memory costs.
> 
> This means if linux is built with a baremetal toolchain the vdso.so
> may not have unwind tables which breaks our (undocumented) platform
> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
> explicitly to the vgettimeofday.o cflags would be nice (the other
> objects in the vdso seem to be asm).
> 
> There was also a report that android clang built linux vdso.so lacks
> .eh_frame completely, that may be a missing --eh-frame-hdr or different
> platform ABI on android, Tamas on cc may be able to verify this.

Vincenzo? Looks like this is a regression caused by the move to C -- please
can you take a look?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Vincenzo Frascino]

Hi Will,

On 4/28/20 8:34 AM, Will Deacon wrote:
> On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
>> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
>> by default since gcc-8, so now the de facto platform ABI is to allow
>> unwinding from async signal handlers.
>>
>> However on bare metal targets (aarch64-none-elf), and on old gcc,
>> async and sync unwind tables are not enabled by default to avoid
>> runtime memory costs.
>>
>> This means if linux is built with a baremetal toolchain the vdso.so
>> may not have unwind tables which breaks our (undocumented) platform
>> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
>> explicitly to the vgettimeofday.o cflags would be nice (the other
>> objects in the vdso seem to be asm).
>>
>> There was also a report that android clang built linux vdso.so lacks
>> .eh_frame completely, that may be a missing --eh-frame-hdr or different
>> platform ABI on android, Tamas on cc may be able to verify this.
> 
> Vincenzo? Looks like this is a regression caused by the move to C -- please
> can you take a look?
> 

I have already, locally, a patch that addresses the problem presented in this
email, based on Szabolcs comment. I did not post it yet because I was waiting
for Tamas' comment and address everything in one go.

Let me know if you need it before then that.

> Will
> 

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Mark Rutland]

On Tue, Apr 28, 2020 at 11:54:25AM +0100, Vincenzo Frascino wrote:
> Hi Will,
> 
> On 4/28/20 8:34 AM, Will Deacon wrote:
> > On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
> >> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
> >> by default since gcc-8, so now the de facto platform ABI is to allow
> >> unwinding from async signal handlers.
> >>
> >> However on bare metal targets (aarch64-none-elf), and on old gcc,
> >> async and sync unwind tables are not enabled by default to avoid
> >> runtime memory costs.
> >>
> >> This means if linux is built with a baremetal toolchain the vdso.so
> >> may not have unwind tables which breaks our (undocumented) platform
> >> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
> >> explicitly to the vgettimeofday.o cflags would be nice (the other
> >> objects in the vdso seem to be asm).
> >>
> >> There was also a report that android clang built linux vdso.so lacks
> >> .eh_frame completely, that may be a missing --eh-frame-hdr or different
> >> platform ABI on android, Tamas on cc may be able to verify this.
> > 
> > Vincenzo? Looks like this is a regression caused by the move to C -- please
> > can you take a look?
> 
> I have already, locally, a patch that addresses the problem presented in this
> email, based on Szabolcs comment. I did not post it yet because I was waiting
> for Tamas' comment and address everything in one go.

Can I suggest that you post the patch as-is here, even if it's not
complete, so that we can all review/test in parallel?

If you do that and explicitly ask Tamas for specific feedback in that
posting, it'll be obvious to everyone what's expected and where things
stand.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Vincenzo Frascino]

Hi Mark,

On 4/28/20 12:11 PM, Mark Rutland wrote:
> On Tue, Apr 28, 2020 at 11:54:25AM +0100, Vincenzo Frascino wrote:
>> Hi Will,
>>
>> On 4/28/20 8:34 AM, Will Deacon wrote:
>>> On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
>>>> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
>>>> by default since gcc-8, so now the de facto platform ABI is to allow
>>>> unwinding from async signal handlers.
>>>>
>>>> However on bare metal targets (aarch64-none-elf), and on old gcc,
>>>> async and sync unwind tables are not enabled by default to avoid
>>>> runtime memory costs.
>>>>
>>>> This means if linux is built with a baremetal toolchain the vdso.so
>>>> may not have unwind tables which breaks our (undocumented) platform
>>>> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
>>>> explicitly to the vgettimeofday.o cflags would be nice (the other
>>>> objects in the vdso seem to be asm).
>>>>
>>>> There was also a report that android clang built linux vdso.so lacks
>>>> .eh_frame completely, that may be a missing --eh-frame-hdr or different
>>>> platform ABI on android, Tamas on cc may be able to verify this.
>>>
>>> Vincenzo? Looks like this is a regression caused by the move to C -- please
>>> can you take a look?
>>
>> I have already, locally, a patch that addresses the problem presented in this
>> email, based on Szabolcs comment. I did not post it yet because I was waiting
>> for Tamas' comment and address everything in one go.
> 
> Can I suggest that you post the patch as-is here, even if it's not
> complete, so that we can all review/test in parallel?
> 

Sure, I will write a sensible comment and send it out.

> If you do that and explicitly ask Tamas for specific feedback in that
> posting, it'll be obvious to everyone what's expected and where things
> stand.
> 
> Thanks,
> Mark.
> 

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Will Deacon]

On Tue, Apr 28, 2020 at 12:15:46PM +0100, Vincenzo Frascino wrote:
> On 4/28/20 12:11 PM, Mark Rutland wrote:
> > On Tue, Apr 28, 2020 at 11:54:25AM +0100, Vincenzo Frascino wrote:
> >> On 4/28/20 8:34 AM, Will Deacon wrote:
> >>> On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
> >>>> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
> >>>> by default since gcc-8, so now the de facto platform ABI is to allow
> >>>> unwinding from async signal handlers.
> >>>>
> >>>> However on bare metal targets (aarch64-none-elf), and on old gcc,
> >>>> async and sync unwind tables are not enabled by default to avoid
> >>>> runtime memory costs.
> >>>>
> >>>> This means if linux is built with a baremetal toolchain the vdso.so
> >>>> may not have unwind tables which breaks our (undocumented) platform
> >>>> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
> >>>> explicitly to the vgettimeofday.o cflags would be nice (the other
> >>>> objects in the vdso seem to be asm).
> >>>>
> >>>> There was also a report that android clang built linux vdso.so lacks
> >>>> .eh_frame completely, that may be a missing --eh-frame-hdr or different
> >>>> platform ABI on android, Tamas on cc may be able to verify this.
> >>>
> >>> Vincenzo? Looks like this is a regression caused by the move to C -- please
> >>> can you take a look?
> >>
> >> I have already, locally, a patch that addresses the problem presented in this
> >> email, based on Szabolcs comment. I did not post it yet because I was waiting
> >> for Tamas' comment and address everything in one go.
> > 
> > Can I suggest that you post the patch as-is here, even if it's not
> > complete, so that we can all review/test in parallel?
> > 
> 
> Sure, I will write a sensible comment and send it out.

Thanks!

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64 vdso might miss .eh_frame

[Vincenzo Frascino]

On 4/28/20 12:58 PM, Will Deacon wrote:
> On Tue, Apr 28, 2020 at 12:15:46PM +0100, Vincenzo Frascino wrote:
>> On 4/28/20 12:11 PM, Mark Rutland wrote:
>>> On Tue, Apr 28, 2020 at 11:54:25AM +0100, Vincenzo Frascino wrote:
>>>> On 4/28/20 8:34 AM, Will Deacon wrote:
>>>>> On Wed, Apr 15, 2020 at 10:23:36AM +0100, Szabolcs Nagy wrote:
>>>>>> On aarch64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
>>>>>> by default since gcc-8, so now the de facto platform ABI is to allow
>>>>>> unwinding from async signal handlers.
>>>>>>
>>>>>> However on bare metal targets (aarch64-none-elf), and on old gcc,
>>>>>> async and sync unwind tables are not enabled by default to avoid
>>>>>> runtime memory costs.
>>>>>>
>>>>>> This means if linux is built with a baremetal toolchain the vdso.so
>>>>>> may not have unwind tables which breaks our (undocumented) platform
>>>>>> ABI guarantee in userspace. So adding -fasynchronous-unwind-tables
>>>>>> explicitly to the vgettimeofday.o cflags would be nice (the other
>>>>>> objects in the vdso seem to be asm).
>>>>>>
>>>>>> There was also a report that android clang built linux vdso.so lacks
>>>>>> .eh_frame completely, that may be a missing --eh-frame-hdr or different
>>>>>> platform ABI on android, Tamas on cc may be able to verify this.
>>>>>
>>>>> Vincenzo? Looks like this is a regression caused by the move to C -- please
>>>>> can you take a look?
>>>>
>>>> I have already, locally, a patch that addresses the problem presented in this
>>>> email, based on Szabolcs comment. I did not post it yet because I was waiting
>>>> for Tamas' comment and address everything in one go.
>>>
>>> Can I suggest that you post the patch as-is here, even if it's not
>>> complete, so that we can all review/test in parallel?
>>>
>>
>> Sure, I will write a sensible comment and send it out.
>

I sent out a patch that addresses the problem reported by Szabolcs [1].

@Tamas, I have few questions:
 - Could you please provide more details on the problem you are facing?
 - Does the solution proposed by Szabolcs address it (--eh-frame-hdr)?

[1]
https://lore.kernel.org/linux-arm-kernel/20200428133411.44092-1-vincenzo.frascino@arm.com/

> Thanks!
> 
> Will
> 

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel