Signed-off-by: Yann Sionneau <ysionneau(a)kalray.eu>
---
libpthread/nptl/sysdeps/riscv64/libc-tls.c | 2 +-
libpthread/nptl/sysdeps/riscv64/tls.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libpthread/nptl/sysdeps/riscv64/libc-tls.c b/libpthread/nptl/sysdeps/riscv64/libc-tls.c
index 500de1d..67c3a60 100644
--- a/libpthread/nptl/sysdeps/riscv64/libc-tls.c
+++ b/libpthread/nptl/sysdeps/riscv64/libc-tls.c
@@ -17,7 +17,7 @@
#include <sysdeps/generic/libc-…
[View More]tls.c>
#include <dl-tls.h>
-/* On OpenRISC, linker optimizations are not required, so __tls_get_addr
+/* On RISC-V 64, linker optimizations are not required, so __tls_get_addr
can be called even in statically linked binaries. In this case module
must be always 1 and PT_TLS segment exist in the binary, otherwise it
would not link. */
diff --git a/libpthread/nptl/sysdeps/riscv64/tls.h b/libpthread/nptl/sysdeps/riscv64/tls.h
index 33a3781..8295c71 100644
--- a/libpthread/nptl/sysdeps/riscv64/tls.h
+++ b/libpthread/nptl/sysdeps/riscv64/tls.h
@@ -1,4 +1,4 @@
-/* Definition for thread-local data handling. NPTL/OR1K version.
+/* Definition for thread-local data handling. NPTL/RISCV64 version.
Copyright (C) 2005, 2007, 2011 Free Software Foundation, Inc.
This file is part of the GNU C Library.
@@ -70,7 +70,7 @@ register tcbhead_t *__thread_self __asm__("tp");
* ------------------------------------
* | PRE | TCB | TLS MEMORY .. |
* ------------------------------------
- * ^ r10 / TP
+ * ^ x4 / TP
*
* PRE is the struct pthread described below
* TCB is tcbhead_t
--
1.8.3.1
[View Less]
Hello,
About
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=858ffad2170762…
I'm not sure why exactly sizeof(int)*3 in the following line:
char buf[sizeof "/proc/self/fd/" + sizeof (int) * 3];
IIUC, this is supposed to give room for the ascii decimal representation
of the file descriptor number.
Maybe we could read the max file descriptor number configured in the
kernel from "/proc/sys/fs/file-max" (or "/proc/sys/file-max" for old
systems?).
So:
1/ fopen("/proc/sys/fs/…
[View More]file-max", "r");
2/ fscanf(fp, "%d", &fdmax);
3/ fdmax_length = log10(fdmax);
Then use fdmax_length
Or, much simpler: take for granted that fd is always an int, and thus
max 32 bits, and hard code that max "string length" of a file descriptor
is 10 chars.
But in any case maybe add a comment on top of the line to explain the
"magic number".
Cheers!
--
Yann
[View Less]
Hi,
This diff fixes a typo in the PTRACE_EVENT_SECCOMP event code.
The typo itself was introduced in 2012 when syncing with glibc header
files and was itself fixed in 2013 in the glibc headers.
diff --git a/libc/sysdeps/linux/common/sys/ptrace.h b/libc/sysdeps/linux/common/sys/ptrace.h
index 6b3c7b574..ebafe4e27 100644
--- a/libc/sysdeps/linux/common/sys/ptrace.h
+++ b/libc/sysdeps/linux/common/sys/ptrace.h
@@ -171,7 +171,7 @@ enum __ptrace_eventcodes
PTRACE_EVENT_EXEC = 4,
…
[View More]PTRACE_EVENT_VFORK_DONE = 5,
PTRACE_EVENT_EXIT = 6,
- PTRAVE_EVENT_SECCOMP = 7
+ PTRACE_EVENT_SECCOMP = 7
};
/* Perform process tracing functions. REQUEST is one of the values
.joris
[View Less]
Hi,
The getenv() library call can trap under certain conditions. It compares the passed in environment variable name (var) with the name=variables (*ep) in the environment area and returns a pointer to the value in the environment if it exists. To accomplish this, it does a memcmp() using the length of the passed in name (len) for each environment variable (*ep) against the passed in name (var). So memcmp will attempt to scan both strings for len bytes. However, if for some reason, len is …
[View More]equal to or greater than 16 and longer than the length of the *ep in the environment and the *ep resides near the end of a page boundary while the next page is not present or mapped, the memcmp could trap with a sigsegv error while continuing the scan with the optimization read-ahead. However, if strncmp is used instead, there is no problem since both source and destination scanning will stop when either reaches a terminating NULL
Test case: We are using gcc 4.8.5 and uclibc 1.0.31. With a small environment area, attempt to do a getenv() using a variable name such as "1234567890123456". Example: file run.c contains:
#include <stdlib.h>
#include <stdio.h>
int main()
{
char *n;
n = getenv("1234567890123456");
printf("Return val: \"%s\"\n", n);
return 0;
}
Then
<sh> cc run.c -o run
<sh> env -i 123=123 ./run.
Segmentation fault
Proposed fix:
--- uclibc/libc/stdlib/getenv.c 2019-11-13 17:22:26.260187664 -0500
+++ uclibc/libc/stdlib/getenv.c 2019-11-13 17:22:39.376111771 -0500
@@ -20,7 +20,7 @@
return NULL;
len = strlen(var);
while(*ep) {
- if (memcmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
+ if (strncmp(var, *ep, len) == 0 && (*ep)[len] == '=') {
return *ep + len + 1;
}
ep++;
Then
<sh> env -i 123=123 ./run.
<sh>
Can we get this patch upstream?
Thanks,
----
John Ata, CISSP
Senior Principal Software Engineer
Electronics Systems
STOP Operating System<http://www.baesystems.com/en-us/product/stop> Software Development
T 703-563-8115 | F 703-668-4359 | john.ata(a)baesystems.com<mailto:john.ata@baesystems.com>
http://www.baesystems.com/csp
[cid:image001.png@01D138BC.8E54E330][cid:image003.png@01D138BC.8E54E330]<http://www.twitter.com/baesystemsinc>[cid:image004.png@01D138BC.8E54E330]<http://www.youtube.com/baesystemsinc>[cid:image006.png@01D138BC.8E54E330]<http://www.flickr.com/photos/baesystemsinc/>
[View Less]