(added port-sun2@)
On 2020/03/09 3:33, Joerg Sonnenberger wrote:
On Sun, Mar 08, 2020 at 06:30:06AM +0000, 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
