5 Nov
2017
5 Nov
'17
10 a.m.
Hi Alexey,
the attached patch fixes at least 3 test suite errors for me.
tst-cancel20/21/4.
Tested with latest 2017.09 ARC binutils/gcc.
Okay to apply?
best regards
Waldemar
6 Nov
6 Nov
10:38 a.m.
Hi Waldemar,
Can you share in which context does this happens, for example by sharing
a .i file for the compilation and point out for the actual location of
the macro expansion?
The reason to request this is to understand if the compiler is not doing
the right thing with blink, as semantically the patched and unpatched
code should be the same, as long as the surrounding code is correct.
It could also be that the problem is not necessarily the blink not being
clobbered but by some other reason it not expecting it to be needed.
Best regards,
Cupertino
On 11/05/2017 11:03 AM, Waldemar Brodkorb wrote:
Hi Alexey,
the attached patch fixes at least 3 test suite errors for me.
tst-cancel20/21/4.
Tested with latest 2017.09 ARC binutils/gcc.
Okay to apply?
best regards
Waldemar
9 Nov
9 Nov
7:17 a.m.
Hi Cupertino,
Cupertino Miranda wrote,
Hi Waldemar,
Can you share in which context does this happens, for example by sharing
a .i file for the compilation and point out for the actual location of
the macro expansion?
The reason to request this is to understand if the compiler is not doing
the right thing with blink, as semantically the patched and unpatched
code should be the same, as long as the surrounding code is correct.
It could also be that the problem is not necessarily the blink not being
clobbered but by some other reason it not expecting it to be needed.
I tried to generate the files for you, but had updated the Linux
kernel before your mail. It seems now that the same test suite tests
are executing fine without the blink removal patch.
Is there any related bugfix made between Linux 4.9.50 and 4.9.60
someone remembers? Strange, I need to verify with 4.9.50 again.
best regards
Waldemar
1:18 p.m.
Hi Waldemar,
I personally made this tst-cancel test start to pass in the past,
related to unwinding issues we had in our tools.
However, I have noticed that some of the tst-cancel tests would have
some non-deterministic behavior.
This was related to some pipes not blocking, when writing some data, but
not blocking.
If I increased the written elements to the pipe, those would block
always, and the test would pass.
It is possible that there was some change in the kernel that might have
fixed this.
Vineet: Do you know anything about this ?
Also be sure you are using our latest tools, as like I said I have
addressed these problems.
Indeed, clobbering blink was an issue when millicode option was enabled.
Regarding your patch I would advise not to apply it until we find the
real reason for blink not to be restored.
Best regards,
Cupertino
On 11/09/2017 08:18 AM, Waldemar Brodkorb wrote:
Hi Cupertino,
Cupertino Miranda wrote,
Hi Waldemar,
Can you share in which context does this happens, for example by sharing
a .i file for the compilation and point out for the actual location of
the macro expansion?
The reason to request this is to understand if the compiler is not doing
the right thing with blink, as semantically the patched and unpatched
code should be the same, as long as the surrounding code is correct.
It could also be that the problem is not necessarily the blink not being
clobbered but by some other reason it not expecting it to be needed.
I tried to
generate the files for you, but had updated the Linux
kernel before your mail. It seems now that the same test suite tests
are executing fine without the blink removal patch.
Is there any related bugfix made between Linux 4.9.50 and 4.9.60
someone remembers? Strange, I need to verify with 4.9.50 again.
best regards
Waldemar
7:09 p.m.
On 11/09/2017 05:18 AM, Cupertino Miranda wrote:
Hi Waldemar,
I personally made this tst-cancel test start to pass in the past,
related to unwinding issues we had in our tools.
However, I have noticed that some of the tst-cancel tests would have
some non-deterministic behavior.
This was related to some pipes not blocking, when writing some data, but
not blocking.
If I increased the written elements to the pipe, those would block
always, and the test would pass.
It is possible that there was some change in the kernel that might have
fixed this.
Vineet: Do you know anything about this ?
Not in ARC port per se.
Regarding your patch I would advise not to apply it
until we find the
real reason for blink not to be restored.
Right. Although in SNPS github uclibc repo we carry an equivalent patch (from
Cuper) for fixing some of the cancelation tests. That is the only out of tree
patch we have in uClibc just because we (I) didn't have time to analyze things
fully. However I'm planning to clean this up and prove that we need that patch
(and submit it for merge) or prove it is useless - which is quite unlikely - since
Cuper is generally NOT smoking pot when coding ;-)
OTOH, while we do need this analysis, the change itself seemed relatively benign,
but was kept on hold due to reasons needing a historic detour (read below if
interested)
In 2010 ? I rewrote the uClibc syscall generators. To reduce generated code bloat
and stack spills for prologue/epilogue etc ernro handling was moved into an
out-of-line function. For fast path case of a simpler successful syscalls (no
errno), no stack operations were needed.
0000c244 <__libc_nanosleep>:
c244: mov r8,162
c248: swi
c24c: brge r0,0,c25c
c250: st.a blink, [sp,-4] # this blink save is from inline
asm - not gcc
c254: bl ad5c # this is errno setter
c258: ld.ab blink, [sp,4]
c25c: j_s [blink]
c25e: nop_s
The proposed change adds blink to clobber list, making BLINK saved twice now (once
by gcc and other due to above) and also undoes all the hand crafted beauty above.
-Vineet
13 Dec
13 Dec
9:31 p.m.
On 11/05/2017 02:03 AM, Waldemar Brodkorb wrote:
Hi Alexey,
the attached patch fixes at least 3 test suite errors for me.
tst-cancel20/21/4.
Tested with latest 2017.09 ARC binutils/gcc.
Okay to apply?
best regards
Waldemar
Are you sure it is the list above.
I presume,
https://tests.embedded-test.org/uClibc-ng/1.0.26/REPORT.arcv2.libc.uClibc-n…
didn't have this fix and yet the tests mentioned above are PASS there.
The reason I ask is because in my experiments here with ARC GNU 2017.09 + uClibc
with and w/o this patch (actually not exactly same, but similar - attached), I
don't see any consistent PASS(es)
There are some changes to say tst-kill6, tst-oncex3 etc but if you run them 5
times they seem to PASS/FAIL randomly - in either setups
So this patch is not fixing anything IMO. We need to really fix the inherent race
in these tests.
BTW I did post a test case fix for tst-cancel2 and that is now consistently PASS.
-Vineet
16 Dec
16 Dec
7:56 p.m.
Hi Vineet,
Vineet Gupta wrote,
On 11/05/2017 02:03 AM, Waldemar Brodkorb wrote:
Indeed it seems really to depend on which system I have run the
tests with and without the patch.
On my IBM X200 notebook the tests passed after adding the patch.
But on the gcc farm server the tests were still failing.
So it is like you said, the patch does not fix the issue.
best regards
Waldemar
Hi Alexey,
the attached patch fixes at least 3 test suite errors for me.
tst-cancel20/21/4.
Tested with latest 2017.09 ARC binutils/gcc.
Okay to apply?
best regards
Waldemar
Are you sure it is the list above.
I presume,
https://tests.embedded-test.org/uClibc-ng/1.0.26/REPORT.arcv2.libc.uClibc-n…
didn't have this fix and yet the tests mentioned above are PASS there.
The reason I ask is because in my experiments here with ARC GNU 2017.09 +
uClibc with and w/o this patch (actually not exactly same, but similar -
attached), I don't see any consistent PASS(es)
There are some changes to say tst-kill6, tst-oncex3 etc but if you run them
5 times they seem to PASS/FAIL randomly - in either setups
So this patch is not fixing anything IMO. We need to really fix the inherent
race in these tests.
BTW I did post a test case fix for tst-cancel2 and that is now consistently PASS.
2533
days inactive
2574
days old
6 comments
3 participants
participants (3)
-
Cupertino Miranda -
Vineet Gupta -
Waldemar Brodkorb