riscvarchive / riscv-glibc

RISC-V port of GNU's libc

The RISC-V glibc Port is Upstream

The RISC-V glibc port is developed in the upstream glibc repository.

• official releases.
• Bug report

riscv-glibc's Issues

pthread library error

I ran this code on spike and it shows the error :

//This code has 4 threads which individually sorts their arrays of different sizes. Arrays are sorted in groups of 4 and then every thread has to count the number of 1s in its array as well as the array stored in global memory. For ensuring correct access, lock has been used with hashing parameters as a function :
F(processId/2 ------> lock_array_index).

#include<bits/stdc++.h>
#include<pthread.h>
#include<time.h>
#include <unistd.h>
using namespace std;

int shared[] = {1,1,4,7};//shared memory
int sizeS = sizeof(shared)/ sizeof(shared[0]);//size of shared memory
int n = 4;//sizeof threads
int count1[] = {0,0,0,0};// n= 4
int lock2[2] = {0,0};
vector< vector > v;
int k[] = {0,0,0,0};
int rem[] = {0,0,0,0};

int checklock2(int id)
{
if(lock2[id/2] != 0)
checklock2(id);
else
return 1;
}

void *sortingh(void *par)
{
int *id = (int *)par;
rem[*id] = v[*id].size();
while(rem[*id] >=4)
{
sort(v[*id].begin()+k[*id] , v[*id].begin()+k[*id]+4);
rem[*id] = rem[*id]-4;
k[*id]+=4;
}
if(rem[*id] < 4)
sort(v[*id].begin()+k[*id] , v[*id].begin()+k[*id]+rem[*id]);
cout<<endl;
for(int i=0;i<v[*id].size();i++)
cout<<v[*id][i];
cout<<endl;

for(int i=0;i<v[*id].size();i++)
{
	if(v[*id][i] == 1)
	count1[*id]+=1;
}
cout<<count1[*id]<<endl;

int c = checklock2(*id);//waititng	
lock2[*id/2] = 1;
for(int i=0;i<sizeS;i++)
	if(shared[i] == 1)
		count1[*id]+=1;
lock2[*id/2] = 0;

}

int main()
{
for(int i=0;i<n;i++)
v.push_back(vector());
for(int i=0;i<n;i++)
count1[i] = 0;
srand(time(NULL));
int number[n];//n=4
for(int i=0;i<n;i++)
number[i] = i;
for(int i=0;i<4;i++)
{
int randomNumber = rand()%3;//limit of the number of 1s in the subarray
for(int j=0;j<randomNumber;j++)
v[i].push_back(0);
int randomNumber1 = rand()%3;//limit of the number of 1s in the subarray
for(int j=0;j<randomNumber1;j++)
v[i].push_back(1);
int randomNumber2 = rand()%3;//limit of the number of 1s in the subarray
for(int j=0;j<randomNumber2;j++)
v[i].push_back(3);
}
for(int i=0;i<4;i++)
{
for(int j=0;j<v[i].size();j++)
cout<<v[i][j]<<" ";
cout<<endl;
}

pthread_t pid[n];
for(int i=0;i<n;i++)
{
	pthread_create(&pid[i] , NULL ,sortingh, &number[i]);
	pthread_join(pid[i] , NULL);
}
for(int i=0;i<4;i++)
{
	cout<<count1[i]<<" ";
}

}

Execution on Ubuntu 16.04 :
shubh@shubh-HP-Pavilion-Notebook:/Documents$ riscv64-unknown-linux-gnu-g++ testP.cpp -o testP -lpthread
shubh@shubh-HP-Pavilion-Notebook:/Documents$ spike /scratch/tools/riscv/riscv64-unknown-elf/bin/pk testP
z 0000000000000000 ra 0000000000010ce4 sp 000000007f7e7b50 gp 00000000000198e8
tp 0000000000000000 t0 0000000000000000 t1 0000000000000000 t2 0000000000018b40
s0 0000000000000000 s1 0000000000000000 a0 00000000000113c4 a1 0000000000000001
a2 000000007f7e7b58 a3 0000000000015658 a4 00000000000156e8 a5 0000000000000000
a6 000000007f7e7b50 a7 0000000000000000 s2 0000000000000000 s3 0000000000000000
s4 0000000000000000 s5 0000000000000000 s6 0000000000000000 s7 0000000000000000
s8 0000000000000000 s9 0000000000000000 sA 0000000000000000 sB 0000000000000000
t3 ffffffffffffffff t4 0000000000000000 t5 0000000000000000 t6 0000000000000000
pc fffffffffffffffe va fffffffffffffffe insn ffffffff sr 8000000200046020
User fetch segfault @ 0xfffffffffffffffe

Can someone tell me what is the error? If it is the error with the library, please intimate it. I will start working on it.

Interpreter location/name

Once we've settled on the interpreter location and filename, we might need to update the following files:

https://github.com/riscv/riscv-glibc/blob/riscv-next/sysdeps/unix/sysv/linux/riscv/rv64/ldconfig.h
https://github.com/riscv/riscv-glibc/blob/riscv-next/sysdeps/unix/sysv/linux/riscv/rv64/ldd-rewrite.sed
https://github.com/riscv/riscv-glibc/blob/riscv-next/sysdeps/unix/sysv/linux/riscv/configure.in
https://github.com/riscv/riscv-glibc/blob/riscv-next/sysdeps/unix/sysv/linux/riscv/dl-cache.h

By default, stack is executable

This is also the default for most ports, but AArch64, Nios II, and Tile don't do this. Obviously, we should follow their lead, but we need to identify the consequences of this change.

Suboptimal math functions on RV32G?

I was looking at some dumps yesterday and noticed that floor etc are generating soft-float code, but I think that mandatory support for subnormals gives us a float-only way to handle integer conversions. Some rough examples to illustrate the point:

floor:
	fld fa1,1f,a1
	fld fa2,2f,a1
	# raise NV if sNaN, no other purpose
	fadd.d fa3,fa0,fa0
	frflags a0
	# the actual floor happens here, relying on gradual underflow semantics
	# can raise UF or NX, which are suppressed by the flags wrapper
	fmul.d fa0,fa0,fa1,rdn
	# restore exponent; exact; alternately fdiv.d fa0,fa0,fa1
	fmul.d fa0,fa0,fa2
	fmul.d fa0,fa0,fa2
	fsflags a0
	ret

# ceil, round, trunc, nearbyint are the same except for s/rdn/rup,rmm,rtz,/

# the same as nearbyint up to the point where we need to squelch UF but not NX or NV
rint:
	fld fa1,1f,a1
	fld fa2,2f,a1
	frflags a0
	fmul.d fa0,fa0,fa1
	fmul.d fa0,fa0,fa2
	fmul.d fa0,fa0,fa2
	frflags a1
	andi a1,a1,17
	or a0,a0,a1
	fsflags a0
	ret

llrint:
	fld fa1,1f,a0
	fld fa2,2f,a0
	fld fa3,3f,a0
	fld fa4,4f,a0
	# round to integer
	frflags a2
	fmul.d fa0,fa0,fa1
	fmul.d fa0,fa0,fa2
	fmul.d fa0,fa0,fa2

	# read off the high word (nonsense if inf/nan)
	fmul.d fa1,fa0,fa3
	fcvt.w.d a1,fa1,rdn

	# adjust
	fcvt.d.w fa1,a1
	fnmsub.d fa1,fa1,fa4,fa0

	fsflags a2

	# Needs proof:
	# At this point, fa1 is in range for a fcvt.wu.d iff
	# fa0 was in range for llrint
	fcvt.wu.d a0,fa1,rne
	ret

	.align 3
1:	.int 1,0  # 0x1.p-1074
2:	.int 0,0x61800000 # 0x1.p+537
3:	.int 0,0x3df00000 # 0x1.p-32
4:	.int 0,0x41f00000 # 0x1.p+32

1. Is this code actually correct, or can it be made such? Is the idea completely off base?
2. Is this worth doing on RV64G? Fewer instructions but could be much worse on hardware without fast subnormal support.
3. In a FENV_ACCESS OFF context, inlining floor into functions with loops becomes an attractive prospect; 3 instructions are only needed for flag setting and can be deleted, 4 more can be hoisted, leaving only 3

Why do we remove the F-ABI?

Hi,
We want to build a toolchain that supports rv64imafc/lp64f, but it seems that riscv-glibc doesn't support it. It looks that the F-ABI is removed in ecbbe9a . It would be great if someone could help me. Thanks in advance :-)

timezone update not working tzdb-2021a on cross compile linux platform

I have upgraded the 3pp timezone to tzdb-2021a, but found that the time on my linux (32bit) box doesn't change according to timezone.
So I guess it's a glibc issue since glibc handles the timezone update.
The way we set timezone is creating a symlink /etc/localtime and it points to /tmp/localtime that we write the actual timezone in. This works well using tzdb-2020a.
I guess the glibc doesn't parse the new timezone file correctly.

warning: unused variable 'refsym'

we see this warning

dl-runtime.c: In function '_dl_fixup':
dl-runtime.c:74:20: warning: unused variable 'refsym' [-Wunused-variable]
const ElfW(Sym) *refsym = sym;
^~~~~~

It seems to be wrongly, generated since refsym is really used in last function call before return

definition
https://github.com/riscv/riscv-glibc/blob/riscv-glibc-2.26/elf/dl-runtime.c#L74

Use
https://github.com/riscv/riscv-glibc/blob/riscv-glibc-2.26/elf/dl-runtime.c#L149

I think real issue would be in gcc if this warning turns out to be unneeded. Workaround is to use
--disable-werror to configure glibc, I thought it would be better to keep this note open.

Building glibc

Hi,

I'm trying to build glibc, I seem to have a working stage1 toolchain. Any idea what the problem might be?

make  subdir=sunrpc -C sunrpc ..=../ others
make[2]: Entering directory '/tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/source/sunrpc'
gcc   -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE -DIS_IN_build -include /tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/build/config.h rpc_main.c \
	-o /tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/build/sunrpc/cross-rpc_main.o -MMD -MP -MF /tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/build/sunrpc/cross-rpc_main.o.dt -MT /tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/build/sunrpc/cross-rpc_main.o -c
In file included from rpc_main.c:37:0:
/gnu/store/sjg2km4jy29wbwpisaab8z0jl5h9v9mn-riscv-glibc-2.24.90-1.e84d3a5-checkout/include/errno.h:3:26: fatal error: stdlib/errno.h: No such file or directory
 #include <stdlib/errno.h>
                          ^
compilation terminated.
make[2]: *** [Makefile:170: /tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/build/sunrpc/cross-rpc_main.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/source/sunrpc'
make[1]: *** [Makefile:215: sunrpc/others] Error 2
make[1]: Leaving directory '/tmp/guix-build-glibc-cross-riscv64-unknown-linux-gnu-2.24.90-1.e84d3a5.drv-0/source'
make: *** [Makefile:9: all] Error 2

mcontext_t type is missing from ucontext.h

The riscv-glibc-2.26 branch (id 4e29434) builds without any problems for RISC-V 32bit, however a number of packages fail to build against the resulting library/toolchain (tested using Buildroot) because the mcontext_t type is missing from ucontext.h. The following patch fixes this issue by moving the definition of mcontext_t outside of the '#ifdef __USE_MISC' structure as per later versions of glibc.

diff --git a/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h b/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h
index 8f02f09106..b9dd04564a 100644
--- a/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h
+++ b/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h
@@ -48,12 +48,11 @@ typedef greg_t gregset_t[NGREG];
 
 /* Container for floating-point state.  */
 typedef union __riscv_fp_state fpregset_t;
+#endif
 
 /* Context to describe whole processor state.  */
 typedef struct sigcontext mcontext_t;
 
-#endif
-
 /* Userlevel context.  */
 typedef struct ucontext
   {
-- 
2.19.1

Is this repo still active?

Looks like there has not been a commit in over a year. Should this be archived?

Please make sure that the file structures use 64-bit offsets only

Hi,

Just a reminder after a conversation with Palmer: Please make sure that only 64-bit offsets are used, even for the 32-bit ISA.

Similar to the case of time_t and the problems with 32-bits, all new ISAs should use 64-bit only offsets for files, to prevent painful migrations or situations in the future.

(For further info: There are probably good explanations and pointers in e-mails from Arnd Bergmann in the riscv-sw mailing list, from around Spring 2016).

Cheers.

%F printf() specifier does not work

%F specifier prints literal "F". Using %f give expected result for printing floats,

printf return positive values for negative float

The %f, %g and %e format specifiers for sprintf() and printf() fail to return the proper sign. The result varies depending upon the mix of printf() calls...

The following produces the incorrect sign for all three of the printf() calls:

$ cat /tmp/negfloat.c

#include <stdio.h>
#include <stdint.h>

int main(int argc, char **argv)
{
    char buf[1024];
    float minusOnePtOne = -1.1;

    printf("%+f\n", minusOnePtOne);
    printf("%+g\n", minusOnePtOne);
    printf("%+e\n", minusOnePtOne);

}
$ riscv64-unknown-elf-gcc -o /tmp/negfloat-rv64 /tmp/negfloat.c
$ spike pk /tmp/negfloat-rv64 
+1.100000
+1.1
+1.100000e+00
$

It appears that just adding a single sprintf() call before the printf() calls forces them to return the correct results:

$ cat /tmp/negfloat.c

#include <stdio.h>
#include <stdint.h>

int main(int argc, char **argv)
{
    char buf[1024];
    float minusOnePtOne = -1.1;

    sprintf(buf, "%+f", minusOnePtOne);

    printf("%+f\n", minusOnePtOne);
    printf("%+g\n", minusOnePtOne);
    printf("%+e\n", minusOnePtOne);

}
$ riscv64-unknown-elf-gcc -o /tmp/negfloat-rv64 /tmp/negfloat.c
$ spike pk /tmp/negfloat-rv64
-1.100000
-1.1
-1.100000e+00
$

And moving the sprintf() between the first two printf() calls produces the correct result for the second two printf() calls:

$ cat /tmp/negfloat.c 

#include <stdio.h>
#include <stdint.h>

int main(int argc, char **argv)
{
    char buf[1024];
    float minusOnePtOne = -1.1;

    printf("%+f\n", minusOnePtOne);

    sprintf(buf, "%+f", minusOnePtOne);

    printf("%+g\n", minusOnePtOne);
    printf("%+e\n", minusOnePtOne);

}
$ riscv64-unknown-elf-gcc -o /tmp/negfloat-rv64 /tmp/negfloat.c
$ spike pk /tmp/negfloat-rv64
+1.100000
-1.1
-1.100000e+00
$

This is the version of GCC being used:

$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 7.1.1 20170509
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

Dynamic linking fails to detect soft float / hard float mixing

Noticed during libffi testing

Questions: How to compile and run the test for this glibc for risc-v?

Hi,
Do you know how to compile and run the testsuite for this glibc for risc-v?
I'm interested to play with the v4 of submission.
Thanks in advance.

`A' extension and ABI

Right now, the presence of the 'A' extension is exposed in the ABI:

#ifdef __riscv_atomic
typedef volatile int pthread_spinlock_t;
#else
typedef pthread_mutex_t pthread_spinlock_t;
#endif

This is a bug, as we don't support the notion of the ABI depending on the 'A' extension: it just depends on 'F', 'D', and XLEN.

An easy solution is to acquire a global mutex, then non-atomically acquire the spinlock while holding the mutex. Then the spinlock can continue to be an int. The serialization bottleneck is kind of irrelevant, since parallel computers will always have the 'A' extension in practice.

What is the difference of glibc 2.26 and glibc 2.27 in RISC-V implementation

Hi @palmer-dabbelt , as I can see in sysdeps/riscv directory, the glibc 2.27 is even not developed based on glibc 2.26, for glibc 2.26, the memcpy.c and memset.S are implemented, but for glibc 2.27, it is not, and even in latest 2.29, there is no these files, any consideration about this?

Thanks
Huaqi