Hello,
Thanks for this!
dnie...@gmail.com, le lun. 16 juin 2025 23:58:07 +0100, a ecrit:
> diff --git a/hurd/hurdrlimit.c b/hurd/hurdrlimit.c
> index 6cb5045bfe..6b0d8a26a3 100644
> --- a/hurd/hurdrlimit.c
> +++ b/hurd/hurdrlimit.c
> @@ -39,6 +39,11 @@ init_rlimit (void)
>
>for (i = 0; i <
From: Diego Nieto Cid
Check for VM limit RPCs
* config.h.in: add #undef for HAVE_MACH_VM_GET_SIZE_LIMIT and
HAVE_MACH_VM_SET_SIZE_LIMIT.
* sysdeps/mach/configure.ac: use mach_RPC_CHECK to check for
vm_set_size_limit and vm_get_size_limit RPCs in gnumach.defs.
* sysdeps/mach/configu
> > ```
> > ...
> > ../scripts/evaluate-test.sh stdio-common/scanf14 $? false false >
> > /home/1speaker/apt-source/glibc-2.41/build-tree/hurd-i386-libc/stdio-common/scanf14.test-result
> > ```
>
> It seems it is related: without your patch the test passes.
&
se false >
> /home/1speaker/apt-source/glibc-2.41/build-tree/hurd-i386-libc/stdio-common/scanf14.test-result
> ```
It seems it is related: without your patch the test passes.
Samuel
> ---
> sysdeps/mach/hurd/dup3.c | 62 +-
Compare with v1:
Better readability and also check for dup3.
I haven't tested this patch again some stress tests as I don't know why
the `dpkg-buildpackage -B` on my qemu got stuck at:
```
...
../scripts/evaluate-test.sh stdio-common/scanf14 $? false false >
/home/1speaker/apt-sour
> > Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > > > - Run 'apt source glibc', use quilt to apply this patch and build
> > > > the libc package using `dpkg-buildpackage -B`. I got the same error as
> > > > [0].
> > >
Zhaoming Luo, le mer. 05 mars 2025 20:07:56 +0800, a ecrit:
> On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> > Hello,
>
> Thanks for the quick reply.
> >
> > Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > > - Run 'a
On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> Hello,
Thanks for the quick reply.
>
> Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > - Run 'apt source glibc', use quilt to apply this patch and build
> > the libc package usin
Hello,
Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> - Run 'apt source glibc', use quilt to apply this patch and build
> the libc package using `dpkg-buildpackage -B`. I got the same error as
> [0].
>
> [0]:
> https://buildd.debian.org/status/f
This patch is quite conservative, only the first mach_port_mod_ref() is
checked, as I haven't found an elegant way to check both
mach_port_mod_ref()s.
I haven't successfully tested this patch. I have tried several methods to
apply the patch and build but failed:
- Clone the glibc s
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:56 -0500, a ecrit:
> ---
> mach/mig_strncpy.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
> index b0c001d775..dbd0a08e56 100644
> --- a/mach/mig_strncpy.c
> ++
---
mach/mig_strncpy.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
index b0c001d775..dbd0a08e56 100644
--- a/mach/mig_strncpy.c
+++ b/mach/mig_strncpy.c
@@ -6,6 +6,14 @@
vm_size_t
__mig_strncpy (char *dst, const char *src,
.c: No such file or directory.
> > > > ```
> > > >
> > > > I expected it will show me the source code of hurdselect.c.
> > >
> > > You need to download it with `apt source glibc` and cd into it,
> > > otherwise gdb can't magically
ow me the source code of hurdselect.c.
> >
> > You need to download it with `apt source glibc` and cd into it,
> > otherwise gdb can't magically invent it :)
>
> But I invoked the gdb using the following command in $(curl-src)/tests/:
>
> ```
> ~/curl/tests$ ./runtests.pl 546 -g
> ```
You can use
set directories /where/you/put/glibc
Samuel
> timeout=0x103cba4, sigmask=0x0) at ./hurd/hurdselect.c:51
> > 51 ./hurd/hurdselect.c: No such file or directory.
> > ```
> >
> > I expected it will show me the source code of hurdselect.c.
>
> You need to download it with `apt source glibc` and cd into it,
&g
lect.c: No such file or directory.
> ```
>
> I expected it will show me the source code of hurdselect.c.
You need to download it with `apt source glibc` and cd into it,
otherwise gdb can't magically invent it :)
Samuel
Hi,
I'm trying to track the curl failed tests by debugging select() function
(or system call?) defined in glibc using gdb. When I executed `b _hurd_select`
to set a break point and run the program. The gdb stopped at the breakpoint
but it gives me the following info:
```
Thread 2 hit Break
On Sun, Jan 12, 2025 at 11:34:19PM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le lun. 06 janv. 2025 12:39:07 +0800, a ecrit:
> > mach: Add CLOCK_MONOTONIC case in clock_gettime()
> >
> > The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
> > value since boo
Hello,
Zhaoming Luo, le lun. 06 janv. 2025 12:39:07 +0800, a ecrit:
> mach: Add CLOCK_MONOTONIC case in clock_gettime()
>
> The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
> value since bootup. See
>
> https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc4
mach: Add CLOCK_MONOTONIC case in clock_gettime()
The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
value since bootup. See
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1
In this patch, the RPC is used to implemen
Thanks for reviewing.
On 1/3/25 6:52 PM, Sergey Bugaev wrote:
On Fri, Jan 3, 2025 at 1:42 PM Zhaoming Luo wrote:
hurd: Add CLOCK_MONOTONIC case in clock_gettime()
Nitpick: the prefix should be "mach:" instead of "hurd:".
In theory, there could be other targets that also run on Mach, and
sys
On Fri, Jan 3, 2025 at 1:42 PM Zhaoming Luo wrote:
> hurd: Add CLOCK_MONOTONIC case in clock_gettime()
Nitpick: the prefix should be "mach:" instead of "hurd:".
In theory, there could be other targets that also run on Mach, and
sysdeps/mach/clock_gettime.c is only Mach-specific, not Hurd-specifi
submitting the 1/1 patch to
glibc? I think the website mentions I need to mention my assignment form
status. Not sure where to add it. Should I add it in cover-letter?
Zhaoming Luo (1):
hurd: Add CLOCK_MONOTONIC case in clock_gettime()
config.h.in | 3 +++
sysdeps/mach
hurd: Add CLOCK_MONOTONIC case in clock_gettime()
The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
value since bootup. See
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1
In this patch, the RPC is used to implemen
ny function
> and just call it as a function (with attribute noreturn).
That fixes things on my box, I pushed it to the glibc tree.
Samuel
On 22/11/24 17:05 +0100, jann...@gnu.org wrote:
Hello,
We found (<https://lists.gnu.org/archive/html/bug-hurd/2024-11/msg00143.html)
while cross-building glibc-2.39 for the 64bit Hurd, our x86_64-gnu-gcc
removes a THREAD_SETMEM from glibc's sigreturn.c, line 47:
<https://sourceware
Andreas Schwab, le dim. 24 nov. 2024 15:15:43 +0100, a ecrit:
> On Nov 24 2024, Sergey Bugaev wrote:
> > So are you saying that we always must mark any asm statement that
> > might transfer control somewhere else w/o returning as 'asm goto',
> > even if we don't actually need to jump to any of the
On Nov 24 2024, Sergey Bugaev wrote:
> So are you saying that we always must mark any asm statement that
> might transfer control somewhere else w/o returning as 'asm goto',
> even if we don't actually need to jump to any of the C-level labels?
An ordinary asm is not allowed to change flow contro
On Sun, Nov 24, 2024 at 3:58 PM Andreas Schwab wrote:
> > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels
> >
> > “
> > GCC assumes that asm execution falls through to the next statement (if
> > this is not the case, consider using the __builtin_unreachable intrinsic
> > after the
On Nov 24 2024, Samuel Thibault via Gcc-bugs wrote:
> Sergey points me at
>
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels
>
> “
> GCC assumes that asm execution falls through to the next statement (if
> this is not the case, consider using the __builtin_unreachable intrinsic
>
Samuel Thibault, le dim. 24 nov. 2024 12:44:00 +0100, a ecrit:
> Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> > Reduced further:
> >
> > --8<--
> > struct hurd_sigstate;
> >
> > typedef struct
> > {
>
> [... the content doesn't actually matter]
>
> > unsigned int reply_p
Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> Reduced further:
>
> --8<--
> struct hurd_sigstate;
>
> typedef struct
> {
[... the content doesn't actually matter]
> unsigned int reply_port;
> } tcbhead_t;
>
> void
> __sigreturn2 (struct hurd_sigstate *ss, unsigned long *
Reduced further:
--8<--
struct hurd_sigstate;
typedef struct
{
void *tcb;
union dtv *dtv;
unsigned int self_do_no_use;
int __glibc_padding1;
int multiple_threads;
int gscope_flag;
unsigned long sysinfo;
unsigned long stack_guard;
unsigned long pointer_guard;
long __glibc_p
Carlos O'Donell, le lun. 15 juil. 2024 09:09:37 -0400, a ecrit:
> On 7/15/24 7:45 AM, Andreas K. Huettel wrote:
> >>> diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist
> >>> b/sysdeps/mach/hurd/i386/libpthread.abilist
> >>> index fa90cc65..3ea7cb41 100644
> >>> --- a/sysdeps/mach/hurd/i386/li
On 7/15/24 7:45 AM, Andreas K. Huettel wrote:
>>> diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist
>>> b/sysdeps/mach/hurd/i386/libpthread.abilist
>>> index fa90cc65..3ea7cb41 100644
>>> --- a/sysdeps/mach/hurd/i386/libpthread.abilist
>>> +++ b/sysdeps/mach/hurd/i386/libpthread.abilist
>>> @
> > diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist
> > b/sysdeps/mach/hurd/i386/libpthread.abilist
> > index fa90cc65..3ea7cb41 100644
> > --- a/sysdeps/mach/hurd/i386/libpthread.abilist
> > +++ b/sysdeps/mach/hurd/i386/libpthread.abilist
> > @@ -164,3 +164,5 @@ GLIBC_2.32 tss_create F
> >
Hello,
Flavio Cruz, le jeu. 11 juil. 2024 23:37:35 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist
> b/sysdeps/mach/hurd/i386/libpthread.abilist
> index fa90cc65..3ea7cb41 100644
> --- a/sysdeps/mach/hurd/i386/libpthread.abilist
> +++ b/sysdeps/mach/hurd/i386/libpthread.a
; Not saying you shouldn't store the name, but let's think of the space
> > vs performance trade-off and document it.
>
> I don't think pthread_getname_np will be a frequent operation, so it's
> probably not worth storing it inside glibc. That'll make the
> implem
We use thread_get_name and thread_set_name to get and set the thread
name, so nothing is stored in the thread structure since these functions
are supposed to be called sparingly.
One notable difference with Linux is that the thread name is up to 32
chars, whereas Linux's is 16.
Also added a mach_
to store the name locally? Could pthread_getname_np
> call thread_get_name also, if we don't expect it to be a frequent
> operation?
>
> Not saying you shouldn't store the name, but let's think of the space
> vs performance trade-off and document it.
I don't think pthrea
Sergey Bugaev, le mer. 10 juil. 2024 21:07:21 +0300, a ecrit:
> in general, what's this useful for? Debugging, maybe?
Yes, but also because we see more and more software assuming that these
functions are available... (just because they are on Linux)
Samuel
Hi Flavio,
in general, what's this useful for? Debugging, maybe?
Do you expect the process itself to query its threads' names locally,
or do you expect another process (GDB) to issue thread_get_name
remotely?
On Wed, Jul 10, 2024 at 7:04 PM Flavio Cruz wrote:
> diff --git a/htl/pt-internal.h b/
Some notable differences with Linux:
- We are not inheriting the program name.
- The name can be up to 64 chars (versus Linux's 16).
Also added a mach_RPC_CHECK to check for the existing of gnumach RPCs.
---
config.h.in | 3 +
htl/Makefile
H.J. Lu, le mar. 09 juil. 2024 09:01:35 +0800, a ecrit:
> On Tue, Jul 9, 2024, 8:55 AM Samuel Thibault <[1]samuel.thiba...@gnu.org>
> wrote:
>
> This change fixes this by adding the version dependency only on x86_64
> Linux.
>
>
> That is wrong. Your patch checks the
> building system,
version dependency for x86_64. But
>> on x86_64 GNU/Hurd, there has never been a glibc 2.36 port, and thus the
>> GLIBC_2.36 version is not defined. The additional version dependency is
>> thus spurious and produces binaries that cannot be executed:
>>
>> ./t
On Tue, Jul 9, 2024, 8:55 AM Samuel Thibault
wrote:
> 916730425594 ("elf: Add elf_backend_add_glibc_version_dependency")
> introduced adding an extra GLIBC_2.36 version dependency for x86_64. But
> on x86_64 GNU/Hurd, there has never been a glibc 2.36 port, and thus the
>
916730425594 ("elf: Add elf_backend_add_glibc_version_dependency")
introduced adding an extra GLIBC_2.36 version dependency for x86_64. But
on x86_64 GNU/Hurd, there has never been a glibc 2.36 port, and thus the
GLIBC_2.36 version is not defined. The additional version dependency is
thu
Hello,
Sergey Bugaev, le lun. 25 mars 2024 15:24:14 +0300, a ecrit:
> On Mon, Mar 25, 2024 at 2:58 PM Florian Weimer wrote:
> > > I think the intent here is to initialize _dl_pagesize with a
> > > conservative default, to avoid initialization ordering issues.
> > > EXEC_PAGESIZE is supposed to be
to binary loading (despite its name -- perhaps it has
been historically related to segment alignment in some old versions of
Linux?) that has been co-opted by glibc for pre-initializing
dl_pagesize, for dubious reasons. It also seems to be a Linux- (and
x86 Hurd) specific thing; I cannot find it in the BSDs.
Which one is it?
Sergey
* Sergey Bugaev:
> We could define EXEC_PAGESIZE to some conservative value on
> aarch64-gnu too, if it turns out that this little workaround is really
> required. But it seems cleaner to make sure we don't need to, as
> Roland's email suggests, and introducing a new port that doesn't have
> a fix
Hello,
On Mon, Mar 25, 2024 at 2:58 PM Florian Weimer wrote:
> > I think the intent here is to initialize _dl_pagesize with a
> > conservative default, to avoid initialization ordering issues.
> > EXEC_PAGESIZE is supposed to be largest supported page size.
>
> This was committed without addressi
* Florian Weimer:
> * Sergey Bugaev:
>
>> diff --git a/elf/dl-support.c b/elf/dl-support.c
>> index 2f502c8b..6375dc95 100644
>> --- a/elf/dl-support.c
>> +++ b/elf/dl-support.c
>> @@ -135,7 +135,11 @@ void *_dl_random;
>> #include
>> #include
>>
>> -size_t _dl_pagesize = EXEC_PAGESIZE;
>> +
We would like to avoid statically defining any specific page size on
aarch64-gnu, and instead make sure that everything uses the dynamic
page size, available via vm_page_size and GLRO(dl_pagesize).
There are currently a few places in glibc that require EXEC_PAGESIZE
to be defined. Per Roland&#
* Sergey Bugaev:
> diff --git a/elf/dl-support.c b/elf/dl-support.c
> index 2f502c8b..6375dc95 100644
> --- a/elf/dl-support.c
> +++ b/elf/dl-support.c
> @@ -135,7 +135,11 @@ void *_dl_random;
> #include
> #include
>
> -size_t _dl_pagesize = EXEC_PAGESIZE;
> +size_t _dl_pagesize
> +#ifdef EX
Applied, thanks!!
Flavio Cruz, le sam. 17 févr. 2024 15:25:35 -0500, a ecrit:
> Tested with the tests provided by glibc plus some other toy examples.
> ---
> sysdeps/mach/hurd/x86_64/Makefile | 4 +
> sysdeps/mach/hurd/x86_64/__start_context.S | 49 +
> sy
Tested with the tests provided by glibc plus some other toy examples.
---
sysdeps/mach/hurd/x86_64/Makefile | 4 +
sysdeps/mach/hurd/x86_64/__start_context.S | 49 +
sysdeps/mach/hurd/x86_64/getcontext.S | 68
sysdeps/mach/hurd/x86_64/makecontext.c | 119
Looks much nicer, applied, thanks! :D
Flavio Cruz, le sam. 17 févr. 2024 11:48:46 -0500, a ecrit:
> ---
> config.h.in| 3 +
> sysdeps/mach/hurd/configure| 174 +
> sysdeps/mach/hurd/configure.ac | 19
> sysdeps/mach/hurd/getrusage.c
---
config.h.in| 3 +
sysdeps/mach/hurd/configure| 174 +
sysdeps/mach/hurd/configure.ac | 19
sysdeps/mach/hurd/getrusage.c | 8 +-
sysdeps/mach/hurd/times.c | 18 +++-
5 files changed, 219 insertions(+), 3 deletions(-)
dif
Flavio Cruz, le ven. 16 févr. 2024 13:26:30 -0500, a ecrit:
> diff --git a/sysdeps/mach/configure.ac b/sysdeps/mach/configure.ac
> index 730fb25d..db1e453f 100644
> --- a/sysdeps/mach/configure.ac
> +++ b/sysdeps/mach/configure.ac
Mach is not necessarily about hurd :)
Better put it in sysdeps/mac
---
config.h.in | 3 +++
sysdeps/mach/configure| 28
sysdeps/mach/configure.ac | 9 +
sysdeps/mach/hurd/getrusage.c | 8 ++--
sysdeps/mach/hurd/times.c | 18 +-
5 files changed, 63 insertions(+), 3 deleti
We would like to avoid statically defining any specific page size on
aarch64-gnu, and instead make sure that everything uses the dynamic
page size, available via vm_page_size and GLRO(dl_pagesize).
There are currently a few places in glibc that require EXEC_PAGESIZE
to be defined. Per Roland&#
For i686, this change is no op but for x86_64 it forces all inlined port
rights to be 8 bytes long.
---
hurd/intr-msg.c| 26 --
mach/msg-destroy.c | 12 +---
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/hurd/intr-msg.c b/hurd/intr-msg.c
index
Hello,
Flavio Cruz, le ven. 24 nov. 2023 16:30:38 -0500, a ecrit:
> @@ -215,11 +237,11 @@ _hurd_intr_rpc_mach_msg (mach_msg_header_t *msg,
> data = (char *) ty + sizeof (mach_msg_type_t);
> }
>
> + /* Calculate length of data in bytes. */
> co
For i686, this change is no op but for x86_64 it forces all inlined port
rights to be 8 bytes long.
---
hurd/intr-msg.c| 26 --
mach/msg-destroy.c | 12 +---
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/hurd/intr-msg.c b/hurd/intr-msg.c
index
Applied, thanks!
Flavio Cruz, le dim. 19 nov. 2023 00:08:47 -0500, a ecrit:
> Existing MiG does not support untyped messages and the Hurd will
> continue to use typed messages for the foreseeable future.
> ---
> hurd/hurdfault.c | 4 ---
> hurd/intr-msg.c| 69 --
Existing MiG does not support untyped messages and the Hurd will
continue to use typed messages for the foreseeable future.
---
hurd/hurdfault.c | 4 ---
hurd/intr-msg.c| 69 --
mach/msg-destroy.c | 64 --
m
Applied, thanks!
Flavio Cruz, le sam. 18 nov. 2023 18:18:44 -0500, a ecrit:
> The `ty` pointer is only set at the end of the loop so that
> `msgtl_header.msgt_inline` and `msgtl_header.msgt_deallocate` remain
> valid. Also, when deallocating memory, we use the length from the
> message directly ra
The `ty` pointer is only set at the end of the loop so that
`msgtl_header.msgt_inline` and `msgtl_header.msgt_deallocate` remain
valid. Also, when deallocating memory, we use the length from the
message directly rather than hard coding mach_port_t since we want to
deallocate any kind of OOL data.
-
Applied, thanks!
Flavio Cruz, le dim. 05 nov. 2023 23:13:32 -0500, a ecrit:
> ---
> sysdeps/mach/mach_rpc.h | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/sysdeps/mach/mach_rpc.h b/sysdeps/mach/mach_rpc.h
> index 152f057ca7..ed81403be6 100644
> --- a/sysdeps/ma
---
sysdeps/mach/mach_rpc.h | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/sysdeps/mach/mach_rpc.h b/sysdeps/mach/mach_rpc.h
index 152f057ca7..ed81403be6 100644
--- a/sysdeps/mach/mach_rpc.h
+++ b/sysdeps/mach/mach_rpc.h
@@ -20,11 +20,8 @@
/* Macro used by MIG to c
2023 at 4:02 AM Sergey Bugaev wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz
>> wrote:
>> >> > I have made changes so that it does daily builds and I'm able to boot
>> >> small prog
i, May 19, 2023 at 9:43 AM Flávio Cruz
> wrote:
> >> > I have made changes so that it does daily builds and I'm able to boot
> >> small programs. However, I haven't had the time to boot programs built
> >> against Glibc. How do you package and boot
On Fri, May 26, 2023 at 10:43 AM Sergey Bugaev wrote:
> On Fri, May 26, 2023 at 3:00 PM Flávio Cruz wrote:
> > Hi Sergey
>
> Hi,
>
> > Thanks for the instructions. I was able to make it work and pushed my
> changes to Github.
>
> That's awesome news -- thank you!
>
> (Well, I figured as much fro
On Fri, May 26, 2023 at 3:00 PM Flávio Cruz wrote:
> Hi Sergey
Hi,
> Thanks for the instructions. I was able to make it work and pushed my changes
> to Github.
That's awesome news -- thank you!
(Well, I figured as much from looking at the GitHub, but it's nice to
get a confirmation.)
What we
s and I'm able to boot
>> small programs. However, I haven't had the time to boot programs built
>> against Glibc. How do you package and boot the static binaries using a
>> ramdisk? I've been reading the other threads about the Guix/rumpkernel so I
>> m
Hi Sergey
On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote:
> Hi,
>
> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote:
> > I have made changes so that it does daily builds and I'm able to boot
> small programs. However, I haven't had the time to boot programs b
Applied, thanks!
Flavio Cruz, le lun. 22 mai 2023 01:16:50 -0400, a ecrit:
> We need to include hurd.h for libc_hidden_proto (__hurd_thread_self),
> introduced in
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b44c1e12524bb5de0f93294a7c24c8e41c06bb75
>
> This the error log:
>
> In fil
We need to include hurd.h for libc_hidden_proto (__hurd_thread_self),
introduced in
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b44c1e12524bb5de0f93294a7c24c8e41c06bb75
This the error log:
In file included from :
./../include/libc-symbols.h:472:33: error: '__EI___hurd_thread_self' ali
Hi,
On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote:
> I have made changes so that it does daily builds and I'm able to boot small
> programs. However, I haven't had the time to boot programs built against
> Glibc. How do you package and boot the static binaries using a ra
ing booting and working on x86_64 with your cross-hurd
> mini-distro. I see you have pushed the buildsystem changes to build
> for x86_64-gnu; have you tried to get it working?
I have made changes so that it does daily builds and I'm able to boot small
programs. However, I haven&#
Applied, thanks!
Flavio Cruz, le mar. 16 mai 2023 22:59:24 -0400, a ecrit:
> This hasn't caused any problems yet but we are passing a pointer to struct
> task_thread_times_info which can cause problems if we populate over the
> existing size of the struct.
> ---
> sysdeps/mach/clock_gettime.c | 2
This hasn't caused any problems yet but we are passing a pointer to struct
task_thread_times_info which can cause problems if we populate over the
existing size of the struct.
---
sysdeps/mach/clock_gettime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/mach/clock_ge
d in whether you would be able to get
something booting and working on x86_64 with your cross-hurd
mini-distro. I see you have pushed the buildsystem changes to build
for x86_64-gnu; have you tried to get it working?
I'll soon post another series of glibc fixes, so maybe consider trying
them out be
On Mon, May 15, 2023 at 2:19 AM Sergey Bugaev wrote:
> Hi,
>
> On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote:
> > If we want
> > ./configure to check if MiG generates code to call the server reply
> routine
> > in case of errors (it doesn't :() then we will need to build a different
> check.
On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev wrote:
> On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote:
> > If we want
> > ./configure to check if MiG generates code to call the server reply routine
> > in case of errors (it doesn't :() then we will need to build a different
> > check.
>
> Huh
Hi,
On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote:
> If we want
> ./configure to check if MiG generates code to call the server reply routine
> in case of errors (it doesn't :() then we will need to build a different
> check.
Huh? Why would MIG call that? Maybe I'm missing some context. Her
Hi Sergey
On Wed, May 10, 2023 at 1:36 AM Sergey Bugaev wrote:
> Hello,
>
> On Wed, May 10, 2023, 08:21 Flavio Cruz wrote:
> > HAVE_MIG_RETCODE is removed completely since this will be a no-op either
> > way (compiling against old Hurd headers will work the same, new Hurd
> > headers will resul
Applied, thanks!
Flavio Cruz, le mer. 10 mai 2023 01:20:34 -0400, a ecrit:
> We already did the same change for Hurd
> (https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=ef5924402864ef049f40a39e73967628583bc1a4)
>
> Due to MiG requiring the subsystem to be defined early in order to know
Hello,
On Wed, May 10, 2023, 08:21 Flavio Cruz wrote:
> HAVE_MIG_RETCODE is removed completely since this will be a no-op either
> way (compiling against old Hurd headers will work the same, new Hurd
> headers will result in the same stubs since retcode is a no-op).
It is a no-op currently, but
We already did the same change for Hurd
(https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=ef5924402864ef049f40a39e73967628583bc1a4)
Due to MiG requiring the subsystem to be defined early in order to know the
size of a port, this was causing a division by zero error during ./configure.
We
Applied, thanks!
Flavio Cruz, le dim. 07 mai 2023 13:13:23 -0400, a ecrit:
> ---
> mach/Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mach/Makefile b/mach/Makefile
> index a5d1252f95..2c09c29406 100644
> --- a/mach/Makefile
> +++ b/mach/Makefile
> @@ -123,7
---
mach/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mach/Makefile b/mach/Makefile
index a5d1252f95..2c09c29406 100644
--- a/mach/Makefile
+++ b/mach/Makefile
@@ -123,7 +123,8 @@ user-interfaces := $(filter-out
$(mach-interface-list:%=mach/%) \
endif
# For s
Applied, thanks!
Flavio Cruz, le sam. 06 mai 2023 16:55:10 -0400, a ecrit:
> Summary of changes:
> - Use BAD_TYPECHECK to perform type checking in a cleaner way.
> BAD_TYPECHECK is moved into sysdeps/mach/rpc.h to avoid duplication.
> - Remove assertions for mach_msg_type_t since those won't wor
Summary of changes:
- Use BAD_TYPECHECK to perform type checking in a cleaner way.
BAD_TYPECHECK is moved into sysdeps/mach/rpc.h to avoid duplication.
- Remove assertions for mach_msg_type_t since those won't work for
x86_64.
- Update message structs to use mach_msg_type_t directly.
- Use desi
Flavio Cruz, le ven. 05 mai 2023 00:20:39 -0400, a ecrit:
> + /* TODO: add this assertion for x86_64. */
> +#ifndef __x86_64__
> + _Static_assert (sizeof (uint32_t) == sizeof (mach_msg_type_t),
> + "mach_msg_type_t needs to be the same size as uint32_t");
> +#endif
Now that it
Summary of changes:
- Use BAD_TYPECHECK to perform type checking in a cleaner way.
BAD_TYPECHECK is moved into sysdeps/mach/rpc.h to avoid duplication.
- Remove assertions for mach_msg_type_t since those won't work for
x86_64.
- Update message structs to use mach_msg_type_t directly and rely on
Applied, thanks!
Flavio Cruz via Libc-alpha, le jeu. 04 mai 2023 00:08:12 -0400, a ecrit:
> Summary of the changes:
> - Introduce BAD_TYPECHECK from MiG to make it simpler to do type
> checking.
> - Replace int type with mach_msg_type_t. This assumes that
> mach_msg_type_t is always the same s
Applied, thanks!
Flavio Cruz via Libc-alpha, le jeu. 04 mai 2023 00:06:46 -0400, a ecrit:
> Summary of the changes:
> - Update msg_align to use ALIGN_UP like we have done in previous
> patches. Use it below whenever necessary to avoid repeating the same
> alignment logic.
> - Define BAD_TYPECH
Summary of the changes:
- Introduce BAD_TYPECHECK from MiG to make it simpler to do type
checking.
- Replace int type with mach_msg_type_t. This assumes that
mach_msg_type_t is always the same size as int which is not true for
x86_64.
- Calculate the size and align using PTR_ALIGN_UP, which i
Summary of the changes:
- Update msg_align to use ALIGN_UP like we have done in previous
patches. Use it below whenever necessary to avoid repeating the same
alignment logic.
- Define BAD_TYPECHECK to make it easier to do type checking in a few
places below.
- Update io2mach_type to use desig
1 - 100 of 1034 matches
Mail list logo
