ARC uClibc-ng testsuite runs empty ?

ARC uClibc-ng testsuite runs empty ?

[Vineet Gupta]

Hi Waldemar,

It seems ARC results are no present for recent releases:

e.g. following is empty:
http://tests.embedded-test.org/uClibc-ng/1.0.21/REPORT.arcv2.toolchain.uClibc-ng-1.0.21

The last good one seems to be
http://tests.embedded-test.org/uClibc-ng/1.0.19/REPORT.arcv2.libc.uClibc-ng-1.0.19

Is this due to the init_module/delete_module change which has been reverted after
1.0.21

Thx,
-Vineet

[uclibc-ng-devel] ARC uClibc-ng testsuite runs empty ?

[Waldemar Brodkorb]

Hi Vineet,
Vineet Gupta wrote,

> Hi Waldemar,
> 
> It seems ARC results are no present for recent releases:
> 
> e.g. following is empty:
> http://tests.embedded-test.org/uClibc-ng/1.0.21/REPORT.arcv2.toolchain.uClibc-ng-1.0.21

Toolchain is always empty, it just shows toolchain building runs
fine.
 
> The last good one seems to be
> http://tests.embedded-test.org/uClibc-ng/1.0.19/REPORT.arcv2.libc.uClibc-ng-1.0.19
> 
> Is this due to the init_module/delete_module change which has been reverted after
> 1.0.21

No, the problem is the removal of the testsuite from uClibc-ng.
Now the test suite is compiled as a part of normal applications and 
arc binutils segfaults.

I reported the issue to Alexey last year.
We added your binutils maintainer to the thread.
Yesterday he had again time to reproduce the problem, but there was
some missing information I gave him yesterday.

So may be you can help with this?

It is really blocking any complete regression testing :( 

Sorry for late response, my mailman has disappeared and no
mailinglist mails where sent out for some days.

best regards
 Waldemar

[uclibc-ng-devel] ARC uClibc-ng testsuite runs empty ?

[Vineet Gupta]

On 01/11/2017 12:48 PM, Waldemar Brodkorb wrote:
> I reported the issue to Alexey last year.
> We added your binutils maintainer to the thread.
> Yesterday he had again time to reproduce the problem, but there was
> some missing information I gave him yesterday.
> 
> So may be you can help with this?

It is beyond my area of expertise and Cuper is looking into it, it is in good
hands already ;-)

OTOH the reason I was dabbling into this was to track down tst-getpid2 failure on
ARC as reported in last known reports.

It seems glibc dropped this test and added a new one instead. See commit
0cb313f7cb0e41 ("Fix clone (CLONE_VM) pid/tid reset (BZ#19957)")

I tried copying over tst-clone2 into uClibc (with a hdr include adjustment), but
it seems to runtime fail for me very early (atleast in nSIM).

| [ARCLinux]# ./tst-clone2
| child pid (62) != received pid/tid (0/1606237724)
| parent pid (61) != received pid/tid (0/1606237724)
| [ARCLinux]# random: crng init done
| echo $?
| 2

Can you please double check this for other targets !

> It is really blocking any complete regression testing :( 

I know sucks, lets hope Cuper nails it down quickly.

> Sorry for late response, my mailman has disappeared and no
> mailinglist mails where sent out for some days.

NP.

Thx,
-Vineet

[uclibc-ng-devel] ARC uClibc-ng testsuite runs empty ?

[Waldemar Brodkorb]

Hi,
Vineet Gupta wrote,

> On 01/11/2017 12:48 PM, Waldemar Brodkorb wrote:
> > I reported the issue to Alexey last year.
> > We added your binutils maintainer to the thread.
> > Yesterday he had again time to reproduce the problem, but there was
> > some missing information I gave him yesterday.
> > 
> > So may be you can help with this?
> 
> It is beyond my area of expertise and Cuper is looking into it, it is in good
> hands already ;-)
> 
> OTOH the reason I was dabbling into this was to track down tst-getpid2 failure on
> ARC as reported in last known reports.
> 
> It seems glibc dropped this test and added a new one instead. See commit
> 0cb313f7cb0e41 ("Fix clone (CLONE_VM) pid/tid reset (BZ#19957)")
> 
> I tried copying over tst-clone2 into uClibc (with a hdr include adjustment), but
> it seems to runtime fail for me very early (atleast in nSIM).
> 
> | [ARCLinux]# ./tst-clone2
> | child pid (62) != received pid/tid (0/1606237724)
> | parent pid (61) != received pid/tid (0/1606237724)
> | [ARCLinux]# random: crng init done
> | echo $?
> | 2
> 
> Can you please double check this for other targets !

I have yesterday seen this commit
c579f48edba88380635ab98cb612030e3ed8691e in glibc and would 
like to follow here and remove any PID/TID caching.

Afterwards I can take a look into 0cb313f7cb0e41.
 
> > It is really blocking any complete regression testing :( 
> 
> I know sucks, lets hope Cuper nails it down quickly.

That would be really cool.

best regards
 Waldemar

[uclibc-ng-devel] ARC uClibc-ng testsuite runs empty ?

[Cupertino Miranda]

Hi Waldemar,

I have looked into the OpenADK uclibc-tests segmentation fault at hand.
Although, I haven't fully tested the patch I think it is a fix for the
issue.

Considering how long I took to look into this problem, I decided to
provide you a patch immediately for you to try it.
BTW, in my case, it fails a little further, but because of some
undefined references.
Maybe it is not really a problem on the toolchain.

Best regards,
Cupertino

On 01/11/2017 11:40 PM, Waldemar Brodkorb wrote:
> Hi,
> Vineet Gupta wrote,
>
>> On 01/11/2017 12:48 PM, Waldemar Brodkorb wrote:
>>> I reported the issue to Alexey last year.
>>> We added your binutils maintainer to the thread.
>>> Yesterday he had again time to reproduce the problem, but there was
>>> some missing information I gave him yesterday.
>>>
>>> So may be you can help with this?
>> It is beyond my area of expertise and Cuper is looking into it, it is in good
>> hands already ;-)
>>
>> OTOH the reason I was dabbling into this was to track down tst-getpid2 failure on
>> ARC as reported in last known reports.
>>
>> It seems glibc dropped this test and added a new one instead. See commit
>> 0cb313f7cb0e41 ("Fix clone (CLONE_VM) pid/tid reset (BZ#19957)")
>>
>> I tried copying over tst-clone2 into uClibc (with a hdr include adjustment), but
>> it seems to runtime fail for me very early (atleast in nSIM).
>>
>> | [ARCLinux]# ./tst-clone2
>> | child pid (62) != received pid/tid (0/1606237724)
>> | parent pid (61) != received pid/tid (0/1606237724)
>> | [ARCLinux]# random: crng init done
>> | echo $?
>> | 2
>>
>> Can you please double check this for other targets !
> I have yesterday seen this commit
> c579f48edba88380635ab98cb612030e3ed8691e in glibc and would 
> like to follow here and remove any PID/TID caching.
>
> Afterwards I can take a look into 0cb313f7cb0e41.
>  
>>> It is really blocking any complete regression testing :( 
>> I know sucks, lets hope Cuper nails it down quickly.
> That would be really cool.
>
> best regards
>  Waldemar
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openadk_binutils_fix.patch
Type: text/x-patch
Size: 2906 bytes
Desc: openadk_binutils_fix.patch
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20170113/70fa75ed/attachment.bin>

[uclibc-ng-devel] ARC uClibc-ng testsuite runs empty ?

[Waldemar Brodkorb]

Hi,
Cupertino Miranda wrote,

> Hi Waldemar,
> 
> I have looked into the OpenADK uclibc-tests segmentation fault at hand.
> Although, I haven't fully tested the patch I think it is a fix for the
> issue.
> 
> Considering how long I took to look into this problem, I decided to
> provide you a patch immediately for you to try it.
> BTW, in my case, it fails a little further, but because of some
> undefined references.
> Maybe it is not really a problem on the toolchain.

Works for me! Thanks.
But what do you mean with not a problem with toolchain when
a change to binutils fixes it for me?
Can you explain why this happens for OpenADK but not for buildroot?

best regards
 Waldemar