The function sigdescr_np is supposed to "return the message describing the
signal signum" [1].
However, for the value SIGEMT, it returns a string without real information.
If a user did not know what SIGEMT means before, he won't know it afterwards.
How to reproduce:
$ gcc -Wall foo.c
$ ./a.out
S
The ISO C function thrd_current() crashes in the main thread on glibc/Hurd,
but not on glibc/Linux.
How to reproduce:
$ gcc -Wall foo.c
$ ./a.out
crashes with SIGSEGV.
Seen on Debian GNU/Hurd, with glibc 2.34.
/* Test of thrd_current () function.
Copyright (C) 2011-2022 Free Software Foundatio
The function strerrorname_np is supposed to return non-NULL for all defined
errno values. [1]
On Hurd, for the errnos with names
ED_*
EKERN_*
EMACH_*
EMIG_*
it returns NULL.
How to reproduce:
$ gcc -Wall foo.c
$ ./a.out
Seen on Debian GNU/Hurd, with glibc 2.34.
[1] https://www.gnu.org/s
On 3/9/22 1:26 am, Almudena Garcia wrote:
> Hi:
>
> I've just compiled gnumach from upstream sources, and I noticed that there
> are a freeze in the booting, just in the pci-arbitrer starting.
>
> I attach a screenshot with the problem.
>
> Could you check this?
> Thanks in advance
I saw this f
This allows clean shutdown of all modern x86 machines
(not just qemu) by using the acpi translator to call
into libacpica code.
---
shutdown/Makefile| 2 +-
shutdown/acpi_shutdown.c | 66
shutdown/acpi_shutdown.h | 18 ---
shutdown/shutdown
Provides two new acpi RPCs to sleep the machine and
to get the irq of any pci device. ACPI mode is enabled
by default when the translator is started.
NB: Merging this commit means libacpica is a build dep.
---
acpi/Makefile | 19 +++--
acpi/acpi-ops.c | 83 +
Samuel Thibault wrote:
> > The gnulib code made the assumption that strerror_r always returns a
> > thread-safe untruncated string. This assumption is wrong both on glibc/Linux
> > and on glibc/Hurd.
>
> ? IIRC at least as of glibc master, on Linux it does fill the string
> even on error.
Yes, gl
Almudena Garcia, le ven. 02 sept. 2022 21:24:44 +, a ecrit:
> Yes, I full-upgraded to latest
"latest" remains relative.
Actual versions of hurd, libc0.3 will help to make sure it's actually
"latest".
Samuel
Bruno Haible, le sam. 03 sept. 2022 01:15:13 +0200, a ecrit:
> Samuel Thibault wrote:
> > That's already fixed:
> >
> > https://patchwork.sourceware.org/project/glibc/patch/20220827134844.1263243-2-samuel.thiba...@ens-lyon.org/
> > "Spotted by the libunistring testsuite test-perror2"
>
> Yes, thi
Samuel Thibault wrote:
> That's already fixed:
>
> https://patchwork.sourceware.org/project/glibc/patch/20220827134844.1263243-2-samuel.thiba...@ens-lyon.org/
> "Spotted by the libunistring testsuite test-perror2"
Yes, this was exactly the test case that I investigated as well.
> https://salsa.d
Bruno Haible, le sam. 03 sept. 2022 00:21:31 +0200, a ecrit:
> POSIX [1] requires that the error messages from perror and strerror for
> the same error number are the same:
> "The contents of the error message strings shall be the same as those
>returned by strerror() with argument errno."
>
Hi,
POSIX [1] requires that the error messages from perror and strerror for
the same error number are the same:
"The contents of the error message strings shall be the same as those
returned by strerror() with argument errno."
On glibc/Linux this is fulfilled. On glibc/Hurd this is not true
Yes, I full-upgraded to latest
El viernes 2 de septiembre de 2022, Etienne Brateau escribió:
> Is your hurd and glibc up to date? I remember an issue with switch to new
> version of glibc
>
> Le ven. 2 sept. 2022 à 18:37, Almudena Garcia
> a écrit :
>
> > Then, where could be the problem?
> > C
Almudena Garcia, le ven. 02 sept. 2022 18:37:34 +0200, a ecrit:
> Then, where could be the problem?
“
we need to know how [...] your packages versions etc. to have any idea what
could
be different on your system.
”
Also, possibly your grub boot entry.
Samuel
Is your hurd and glibc up to date? I remember an issue with switch to new
version of glibc
Le ven. 2 sept. 2022 à 18:37, Almudena Garcia
a écrit :
> Then, where could be the problem?
> Check my previous messages
>
> El vie, 2 sept 2022 a las 18:28, Samuel Thibault ()
> escribió:
>
>> Almudena Ga
Then, where could be the problem?
Check my previous messages
El vie, 2 sept 2022 a las 18:28, Samuel Thibault ()
escribió:
> Almudena Garcia, le ven. 02 sept. 2022 18:04:31 +0200, a ecrit:
> > ld: warning: gnumach.o: requires executable stack (because the
> .note.GNU-stack
> > section is executab
Almudena Garcia, le ven. 02 sept. 2022 18:04:31 +0200, a ecrit:
> ld: warning: gnumach.o: requires executable stack (because the .note.GNU-stack
> section is executable)
I have that too. That's a new warning that compains that on stack
overflow vulnerabilities, code can be executable from the stac
Checking building log, I've just find this message
ld: warning: gnumach.o: requires executable stack (because the
.note.GNU-stack section is executable)
Could be this related with my problem?
El vie, 2 sept 2022 a las 18:02, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> After test
After test it again without --enable-cpus, the problems continues
El vie, 2 sept 2022 a las 17:58, Almudena Garcia (<
liberamenso10...@gmail.com>) escribió:
> I pulled from this branch of my repository, which is another pull from
> upstream using "git remote"
> https://github.com/AlmuHS/GNUMach_S
I pulled from this branch of my repository, which is another pull from
upstream using "git remote"
https://github.com/AlmuHS/GNUMach_SMP/tree/master
I compiled it in the host machine using this commands
autoreconf --install
mkdir build
cd build
../configure --host=i686-gnu CC='gcc -m32' LD='ld -m
Hello,
Almudena Garcia, le ven. 02 sept. 2022 17:26:20 +0200, a ecrit:
> I've just compiled gnumach from upstream sources, and I noticed that there are
> a freeze in the booting, just in the pci-arbitrer starting.
>
> I attach a screenshot with the problem.
>
> Could you check this?
Yes, it jus
Hi:
I've just compiled gnumach from upstream sources, and I noticed that there
are a freeze in the booting, just in the pci-arbitrer starting.
I attach a screenshot with the problem.
Could you check this?
Thanks in advance
This exposes network routing table on /proc/route
---
procfs/Makefile | 2 +-
procfs/rootdir.c | 74
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/procfs/Makefile b/procfs/Makefile
index 13ee026c4..d32328d28 100644
--- a/procfs/M
I had to add some code to linux-src
(otherwise reimplement tons of structs).
---
hurd/pfinet.defs | 9 +++
pfinet/iioctl-ops.c | 1 +
pfinet/linux-src/include/net/ip_fib.h | 2 +
pfinet/linux-src/net/ipv4/fib_hash.c | 84 +++
pfin
24 matches
Mail list logo
