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

2020-03-10 Thread Rin Okuyama

(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?


Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-03-10 Thread Santhosh Raju
On Tue, Mar 10, 2020 at 7:25 AM Santhosh Raju  wrote:
> Module Name:src
> Committed By:   fox
> Date:   Mon Mar  9 15:40:50 UTC 2020
> Modified Files:
> src/external/cddl/osnet/dist/uts/common/fs/zfs: metaslab.c
> Log Message:
> external/cddl/osnet: Fix possible null pointer access.
> Detected by UBSan and fixed upstream, pick only the fix from the commit.
> Cherry-pick:
> From 928e8ad47d3478a3d5d01f0dd6ae74a9371af65e Mon Sep 17 00:00:00 2001
> From: Serapheim Dimitropoulos 
> Date: Wed, 20 Feb 2019 09:59:57 -0800
> Subject: [PATCH] Introduce auxiliary metaslab histograms
> Reviewed by: Paul Dagnelie 
> Reviewed-by: Brian Behlendorf 
> Reviewed by: Matt Ahrens 
> Signed-off-by: Serapheim Dimitropoulos 
> Closes #8358
> Reviewed by: kamil@
> To generate a diff of this commit:
> cvs rdiff -u -r1.1.1.3 -r1.2 \
> src/external/cddl/osnet/dist/uts/common/fs/zfs/metaslab.c
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

Forgot to add in the commit log, the changes have been pulled in from
upstream openzfs.