Switch to compiler_rt from assembler codes? (Re: CVS commit: src/lib/libc/compiler_rt)
Rin Okuyama <[email protected]> Tue, 10 Mar 2020 21:59:33 +0900
| Newsgroups | gmane.os.netbsd.devel.cvs.discuss,gmane.os.netbsd.ports.sun2 |
|---|---|
| Message-ID | <[email protected]> |
(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