Re: [PATCH] Port GDB to Hurd x86_64.

On 2/12/24 8:31 PM, Flavio Cruz wrote: This port extends the existing i686 port to support x86_64 by trying to reuse existing code whenever it makes sense. * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and position of amd64 registers in the different Hurd structs, including

Re: Are you doing this too for GNU/Hurd?

Svante Signell, le jeu. 22 févr. 2024 18:13:50 +0100, a ecrit: > On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote: > > Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit: > > > Changes: > > > ... > > >  gcc-13 (13.2.0-14) experimental; urgency=medium > > > * Pass -D_TIME_BITS=64

Re: Are you doing this too for GNU/Hurd?

On 22 Feb 2024, at 17:13, Svante Signell wrote: > On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote: >> Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit: >>> Changes: >>> ... >>> gcc-13 (13.2.0-14) experimental; urgency=medium >>> * Pass -D_TIME_BITS=64 together with

Re: Are you doing this too for GNU/Hurd?

On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit: > > Changes: > > ... > >  gcc-13 (13.2.0-14) experimental; urgency=medium > > * Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by > > default > > on the 32bit

Re: Are you doing this too for GNU/Hurd?

Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit: > Changes: > ... > gcc-13 (13.2.0-14) experimental; urgency=medium > * Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by default > on the 32bit architectures armel, armhf, hppa, m68k, mips, mipsel, > powerpc (-m32

Are you doing this too for GNU/Hurd?

>From the changelog: Changes: ... gcc-13 (13.2.0-14) experimental; urgency=medium * Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by default on the 32bit architectures armel, armhf, hppa, m68k, mips, mipsel, powerpc (-m32 only) and sh4. ...

Re: [PATCH v2 3/3 gnumach] kern/gsync: Use vm_map_lookup with keep_map_locked

Looks much nicer indeed, applied, thanks! Damien Zammit, le jeu. 22 févr. 2024 08:24:39 +, a ecrit: > This prevents a deadlock in smp where a read lock on the map > is taken in gsync and then the map is locked again inside > vm_map_lookup() but another thread had a pre-existing write lock, >

Re: [PATCH v2 1/3 gnumach] vm_map: Add comment and assert for vm_map_delete

Hello, Damien Zammit, le jeu. 22 févr. 2024 08:24:25 +, a ecrit: > + /* > + * Must be called with map lock taken unless refcount is zero > + */ > + assert((map->ref_count > 0 && map->lock.want_write) || (map->ref_count > == 0)); Please rather use have_write_lock().

[PATCH v2 3/3 gnumach] kern/gsync: Use vm_map_lookup with keep_map_locked

This prevents a deadlock in smp where a read lock on the map is taken in gsync and then the map is locked again inside vm_map_lookup() but another thread had a pre-existing write lock, therefore the second read lock blocks. This is fixed by removing the initial gsync read lock on the map but

[PATCH v2 1/3 gnumach] vm_map: Add comment and assert for vm_map_delete

This will prevent calling vm_map_delete without the map locked unless ref_count is zero. --- vm/vm_map.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/vm/vm_map.c b/vm/vm_map.c index e454bb2a..f221c532 100644 --- a/vm/vm_map.c +++ b/vm/vm_map.c @@ -551,10 +551,12 @@ void

[PATCH v2 2/3 gnumach] vm_map_lookup: Add parameter for keeping map locked

This adds a parameter called keep_map_locked to vm_map_lookup() that allows the function to return with the map locked. This is to prepare for fixing a bug with gsync where the map is locked twice by mistake. Co-Authored-By: Sergey Bugaev --- i386/intel/read_fault.c | 4 ++-- kern/gsync.c

[PATCH v2 0/3 gnumach] vm_map and gsync changes

Hi, I addressed the points in review of first round. I tested this patchset using Sergey's patch additionally but dropped it from this set so Sergey can mail in his version instead. It still compiles gnumach with 7 cores using slave_pset. Thanks, Damien