Switch to compiler_rt from assembler codes? (Re: CVS commit: src/lib/libc/compiler_rt)

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

(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