Re: struct sigcontext in Hurd/x86_64

Sergey Bugaev wrote: > Looking at [0]: 'int code' should be 'long code', otherwise you won't > be able to extract the full 64-bit address from it. Good point, thanks! I've changed libsigsegv and gnulib accordingly. > I don't know how > this works out for the BSDs -- maybe they just don't pass

Re: struct sigcontext in Hurd/x86_64

Sergey Bugaev wrote: > state->basic is the Mach i386_thread_state structure; the > signal handling machinery first initializes it using thread_get_state > ()) to describe the state that the thread had at the time it was > interrupted. It then initializes the sigcontext based on this state >

Re: [bug-diffutils] bug#63333: [PATCH] Add hurd-amd64 support

I committed: > 2023-05-12 Bruno Haible > > sigsegv: Add tentative support for Hurd/x86_64. > Reported by Samuel Thibault . > * lib/sigsegv.c: Update from libsigsegv/src/fault-hurd-i386.h. This was not sufficient. Sergey Bugaev pointed out that - my comm

Re: struct sigcontext in Hurd/x86_64

Hello Sergey, > > * glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h lines 57..79 > > * glibc/sysdeps/mach/hurd/x86/trampoline.c lines 239..247. > > This code copies the values from the stack into a 'struct sigcontext'. > > But here the order of the registers is > > No: trampoline.c copies

Re: [bug-diffutils] bug#63333: [PATCH] Add hurd-amd64 support

instead. I'm calling this "tentative" support for Hurd/x86_64, because - I have no way to test it, - some of the code paths involved seem to be incorrect so far, see https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00207.html 2023-05-12 Bruno Haible sigseg

sigsp on Hurd/x86_64

Hi, In the file glibc/sysdeps/mach/hurd/x86/trampoline.c lines 199..204 #ifdef __x86_64__ /* Align SP at 16 bytes. Coupled with the fact that sigreturn_addr is 16-byte aligned within the stackframe struct, this ensures that it ends up on a 16-byte aligned address, as required by the

struct sigcontext in Hurd/x86_64

Hi, While trying to understand the patch submitted at https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00048.html I'm looking at three files: * gnumach/x86_64/locore.S lines 512..519 ENTRY(alltraps) pusha /* save the general registers */

Re: sigdescr_np for SIGEMT is useless

Samuel Thibault wrote: > the foo.c testcase is missing as attachment Oops, sorry. > but please check whether this is a hurd-specific > issue or a generic glibc issue, as we have really much less manpower > than the glibc team in general. Here it is a bug in glibc in general, > and in Linux too

Re: thrd_current crashes in the main thread

Samuel Thibault wrote: > > The ISO C function thrd_current() crashes in the main thread on glibc/Hurd, > That's already fixed in 2.35. Fix now also pending for 2.34-8. Thanks! Cool.

sigdescr_np for SIGEMT is useless

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

thrd_current crashes in the main thread

with this program. If not, see <https://www.gnu.org/licenses/>. */ /* Written by Bruno Haible , 2011. */ #include thrd_t main_thread; int main () { main_thread = thrd_current (); return 0; }

strerrorname_np returns NULL for some defined errno values

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]

Re: strerror and perror / strerror_r error messages differ

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,

Re: strerror and perror / strerror_r error messages differ

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. >

strerror and perror / strerror_r error messages differ

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

bug: pthread TLS/TSS key destructors are not always invoked

warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. */ /* Written by Bruno

posix_spawn[p] less secure on Hurd than on Linux

Hi, In glibc versions < 2.15, posix_spawn and posix_spawnp did execute a script (with execution bits set) even if it did not start with a '#!' marker. Then, /bin/sh was used as an interpreter. You can imagine how easily a text file, which happens to set execution bits set because it was copied

Re: ssh and scp get stuck after some amount of data

Thomas Schwinge wrote: > I thus tried: > > $ pv --rate-limit 1M [file] | ssh [...] 'cat > [file]' > > ..., which crashed after 368 MiB. Probably you need a rate limit smaller than 1 MB/sec, then? Bruno

Re: $ORIGIN substitution in RPATH

Hi Samuel, > > I am 'root', and the executable as well as the shared library are > > executable. Where does the 'Permission denied' error come from? > > That's because initscripts unexpectedly mounts a tmpfs on /tmp, while > that doesn't apparently properly support program execution yet Indeed.

Re: $ORIGIN substitution in RPATH

Samuel Thibault wrote: > ORIGIN support was only commited in 2018-01-08 The commit introduced a new symbol '_hurd_exec_paths' in glibc. But when I write an autoconf test that tests for this symbol,

Re: $ORIGIN substitution in RPATH

Hi Samuel, > I have now fixed the installability and made a newer preinstalled image > on http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ Thanks; this image works fine under VirtualBox. However, my test case for use of $ORIGIN still does not work. How to reproduce: $ wget

Re: $ORIGIN substitution in RPATH

Hi Samuel, > It does work on a recent enough system. > > ORIGIN support was only commited in 2018-01-08 Ah, good to know. I didn't expect it to be a so recent addition. Bruno

$ORIGIN substitution in RPATH

Hi, After reading http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00047.html I was under the impression that $ORIGIN in -rpath arguments passed to the linker would have the same effect under Hurd as on Linux/glibc. But it does not work for me. This is on Hurd 0.9 (using the image from

Re: gnulib's `lock' module v.s. the Hurd's libpthread

Hello, Thomas Schwinge wrote: I'd like to have some input on the following issue. This is the underlying problem of recent (newer than 0.14.5, I think) versions of GNU gettext failing to build for us. Could you please have shown an error log with a precise error message? I found [1] and [2]