Switch to compiler_rt from assembler codes? (Re: CVS commit: src/lib/libc/compiler_rt)
(added port-sun2@)
On 2020/03/09 3:33, Joerg Sonnenberger wrote:
On Sun, Mar 08, 2020 at 06:30:06AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:30:06 UTC 2020
Modified Files:
src/lib/libc/compiler_rt: Makefile.inc
Log Message:
Fix broken printf(3) %d output for numbers more than two digits, e.g.,
printf("%d\n", 42) ---> "::" instead of "42"
Our __{,u}modsi3 codes assume that __udivsi3 returns remainder to
%d1 (volatile register). __udivsi3 in libgcc does not, and therefore
mixing them up results in mess.
This looks like the wrong fix to me. This is not about libgcc at all.
The depency in the src/common code should be fixed IMO. If __{,u}modsi3
wants to make assumptions about the remainder being implicitly computed,
it really should be using the divmod primitive instead.
Strictly speaking, this is bug in __{,u}modsi3. However:
(1) This is for optimization. There is no need for stack push and pop if
they can use our special version of __udivsi3, instead of __divmodsi4.
If they were ``fixed'' correctly, the resulted codes would have no big
difference from the C version provided by compiler_rt.
(2) Problems occur only when they are mixed with libgcc version of
__udivsi3. For standalone programs, i.e., kernel and bootloader, this
``wrong'' version works well.
(3) They are used only for m68000 (68010; sun2). For m68k (68020 and
later; other m68k ports), GCC does not generate references to these
functions at all.
Therefore, I propose:
(A) Continue to use these assembler codes only in standalone programs
(kernel and bootloader). For userland (libc), switch to the C version
provided by compiler_rt. Again, this affects only for 68010, i.e., sun2,
and not for other m68k ports.
Alternatively, we can:
(b) Switch both standalone and userland to compiler_rt.
I've checked both (A) and (B) version of live-image work fine on TME.
I prefer (A) over (B), since there is no problem if they are used only
in a controlled situation. Also, we are suffering from increase in
kernel size on sun2. But how do you everyone think?
Thanks,
rin
Re: CVS commit: src/lib/libc/compiler_rt
On Sun, Mar 08, 2020 at 06:30:06AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Mar 8 06:30:06 UTC 2020
>
> Modified Files:
> src/lib/libc/compiler_rt: Makefile.inc
>
> Log Message:
> Fix broken printf(3) %d output for numbers more than two digits, e.g.,
>
> printf("%d\n", 42) ---> "::" instead of "42"
>
> Our __{,u}modsi3 codes assume that __udivsi3 returns remainder to
> %d1 (volatile register). __udivsi3 in libgcc does not, and therefore
> mixing them up results in mess.
This looks like the wrong fix to me. This is not about libgcc at all.
The depency in the src/common code should be fixed IMO. If __{,u}modsi3
wants to make assumptions about the remainder being implicitly computed,
it really should be using the divmod primitive instead.
Joerg
Re: CVS commit: src/lib/libc/compiler_rt
Oops, forgot to note that this is only for 68010, and other
systems including m68k are not affected.
Thanks,
rin
On 2020/03/08 15:30, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:30:06 UTC 2020
Modified Files:
src/lib/libc/compiler_rt: Makefile.inc
Log Message:
Fix broken printf(3) %d output for numbers more than two digits, e.g.,
printf("%d\n", 42) ---> "::" instead of "42"
Our __{,u}modsi3 codes assume that __udivsi3 returns remainder to
%d1 (volatile register). __udivsi3 in libgcc does not, and therefore
mixing them up results in mess.
To generate a diff of this commit:
cvs rdiff -u -r1.36 -r1.37 src/lib/libc/compiler_rt/Makefile.inc
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/lib/libc/compiler_rt/Makefile.inc
diff -u src/lib/libc/compiler_rt/Makefile.inc:1.36
src/lib/libc/compiler_rt/Makefile.inc:1.37
--- src/lib/libc/compiler_rt/Makefile.inc:1.36 Tue Oct 29 16:08:50 2019
+++ src/lib/libc/compiler_rt/Makefile.inc Sun Mar 8 06:30:06 2020
@@ -1,4 +1,4 @@
-# $NetBSD: Makefile.inc,v 1.36 2019/10/29 16:08:50 joerg Exp $
+# $NetBSD: Makefile.inc,v 1.37 2020/03/08 06:30:06 rin Exp $
COMPILER_RT_SRCDIR= ${NETBSDSRCDIR}/sys/external/bsd/compiler_rt/dist
@@ -170,9 +170,16 @@ GENERIC_SRCS+= \
GENERIC_SRCS+= \
divmodsi4.c \
divsi3.c \
- modsi3.c \
udivmodsi4.c \
+
+. if ${LIBC_MACHINE_ARCH} != "m68000"
+# Our __{,u}modsi3 codes assume that __udivsi3 returns remainder to
+# %d1 (volatile register). __udivsi3 in libgcc does not, and therefore
+# mixing them up results in mess.
+GENERIC_SRCS+= \
+ modsi3.c \
umodsi3.c
+. endif
. if ${LIBC_MACHINE_CPU} != "sh3"
# On sh3 __udivsi3 is gcc "millicode" with special calling convention
Re: CVS commit: src/lib/libc/compiler_rt
On Mon, Dec 02, 2013 at 11:10:43PM -0800, Matt Thomas wrote: > > On Dec 2, 2013, at 6:28 PM, Joerg Sonnenberger wrote: > > > Module Name:src > > Committed By: joerg > > Date: Tue Dec 3 02:28:51 UTC 2013 > > > > Modified Files: > > src/lib/libc/compiler_rt: Makefile.inc > > > > Log Message: > > Add ARM (EABI) specific sources. Split off code that requires C11, > > unwind support in libc or overlaps with soft-float in preparation for > > using compiler-rt in the non-clang case. > > How will interact with libkern? I have a plugin Makefile which is structured similar to this. I'm currently in the process of testing a random subset of architectures for building... Joerg
Re: CVS commit: src/lib/libc/compiler_rt
On Dec 2, 2013, at 6:28 PM, Joerg Sonnenberger wrote: > Module Name: src > Committed By: joerg > Date: Tue Dec 3 02:28:51 UTC 2013 > > Modified Files: > src/lib/libc/compiler_rt: Makefile.inc > > Log Message: > Add ARM (EABI) specific sources. Split off code that requires C11, > unwind support in libc or overlaps with soft-float in preparation for > using compiler-rt in the non-clang case. How will interact with libkern?
