11 Jan
2017
11 Jan
'17
5:53 p.m.
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.uCli…
The last good one seems to be
http://tests.embedded-test.org/uClibc-ng/1.0.19/REPORT.arcv2.libc.uClibc-ng…
Is this due to the init_module/delete_module change which has been reverted after
1.0.21
Thx,
-Vineet
11 Jan
11 Jan
8:48 p.m.
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.uCli…
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…
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
10:26 p.m.
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
10:40 p.m.
Hi,
Vineet Gupta wrote,
That would be really cool.
best regards
Waldemar
On 01/11/2017 12:48 PM, Waldemar Brodkorb wrote:
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.
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. 
13 Jan
13 Jan
3:06 p.m.
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,
That would be really cool.
best regards
Waldemar
On 01/11/2017 12:48 PM, Waldemar Brodkorb wrote:
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.
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.
14 Jan
14 Jan
7:01 p.m.
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
2869
days inactive
2872
days old
5 comments
3 participants
participants (3)
-
Cupertino Miranda -
Vineet Gupta -
Waldemar Brodkorb