Re: PSA: glibc buildbot slave up for aarch64

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

> On 28 Apr 2017, at 13:03, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
>> On Friday 28 April 2017 08:30 PM, Carlos O'Donell wrote:
>> It is better in the long run to mark these XFAIL, associate them with a bug, 
>> and have a green board. The green board makes it immediately easy to identify
>> breakage.
>> 
>> The XFAIL is the encoding of expert knowledge. We _will_ get to fixing issues,
>> but we will do so based on priority order of the things we have in the bugzilla
>> and things identified by the community.
> 
> My concern is that we won't get to fixing things urgently enough given
> that technical debt repayment has not been a priority for us
> traditionally.  That is not to say that nobody does it - we have fixed a
> huge pile of issues over the years.  It is just that we don't invest the
> kind of resources that we should and as a result a number of issues that
> are of medium/low priority stay languishing in there forever.  The red
> buildbot is hopefully enough of an eyesore to get to fixing things
> sooner rather than later.
> 
>>> I would prefer if for now red buildbot statuses become release blockers
>>> for 2.26.  Once 2.26 is released, any failure should either be
>>> immediately fixed or the offending patch reverted.
>> 
>> Why? They might not be important things. Priority is what matters.
> 
> Sure, I can settle for that, marking low priority bugs that nobody cares
> about and are probably not easy to fix anyway as XFAILs.  In that
> context I concede that the backtrace bug fits that description.  Also in
> this context, I'd rather keep the buildbot red for aarch64 to track the
> backtrace fix because the patch is in review and the red status is again
> hopefully an incentive to expedite the review.
> 
> In general though we need to be careful with what we mark as XFAIL with
> the view of making the buildbot statuses green.
> 
> Siddhesh

For the tst-backtrace{5,6} on aarch64 I think we can use the same strategy for PowerPC, where GLIBC saves the vDSO symbol address and use it to get the correct stackstrace on signal handlers. Also, since frame pointer save is required for aarch64 ABI, we can avoid using x86_64 code which uses libgcc and walk the frames directly. I have a local implementation that fixes all current testcases and I will send it for 2.26.