where call will lock the map and otherwise the
map is locked in the else case of the if in the first snippet.
My doubt is what to do the non NULL entry in case result, returned
by the enforcer function, is not KERN_SUCCESS. Wouldn't I be leaking
a vm_map_entry_t?
Diego
On Wed, Jun 25, 2025 at 01:08:31AM +0200, Samuel Thibault wrote:
>
> I meant a vm_protect that changes the maximum protection.
>
Ah, I think we concluded that the maximum protection can only go
into strictier values due to the loop here[1].
More specifically the following if:
if ((/* VM_PR
7;t think I understand your suggestion:
> It would be also useful to check that trying to vm_protect the PROT_NONE
> into PROT_ALL fails when that comes above the limit.
Why would vm_protect fail when upgrading a mmap(PROT_NONE) if the allocated
memory
is already accounted on the size of the vm_map?
Diego
On Tue, Jun 24, 2025 at 03:54:23PM +0200, Samuel Thibault wrote:
>
> Because that is what Linux implements: RLIMIT_AS limits what
> mmap(PROT_NONE) can allocate. Then, changing with mprotect() will not
> change the RLIMIT_AS counting.
>
mmap(PROT_NONE)[1][2] ends up calling vm_map(cur: VM_PROT_NO
ge with current protection (instead of
max protection) set to VM_PROT_NONE and keep track of updates through
vm_protect.
I don't remember why it was implemented against the max protection but switching
shouldn't be a problem.
Regards,
Diego
On Mon, Jun 23, 2025 at 11:18:53PM +0200, Samuel Thibault wrote:
> Diego Nieto Cid, le lun. 23 juin 2025 21:02:03 +0100, a ecrit:
> > On Mon, Jun 23, 2025 at 07:52:00PM +0100, Milos Nikic wrote:
> > >
> > > +/* Called from assembly (locore.S) */
> > &
Hello,
On Mon, Jun 23, 2025 at 07:52:00PM +0100, Milos Nikic wrote:
>
> +/* Called from assembly (locore.S) */
> +void handle_double_fault(struct i386_saved_state *regs);
> +
Shouldn't this prototype be in i386/i386/trap.h which is included by locore.S?
Cheers,
Diego
Hi again :)
On Thu, Jun 19, 2025 at 01:16:20AM +0100, Diego Nieto Cid wrote:
>
> You can also test by installing mig from the Debian repository instead of
> building it from source.
>
If you go that route you would need:
sudo apt install mig-i686-gnu
Or maybe the test makefil
27;
so probably something to do with how the built mig is installed from source.
You can also test by installing mig from the Debian repository instead of
building it from source.
Below[2] are all the steps I went through on a clean hurd-i386 image[1] in
case it is of some help to you.
Regards,
Di
Hi,
On Mon, Jun 16, 2025 at 09:25:21PM -0700, Milos Nikic wrote:
> Hello
>
> And inside hurd it looked like this:
>
>
> $ cd gnumach
> $ git fetch origin
> $ git reset --hard origin/master
> $ autoreconf -i
> $ mkdir build
> $ cd build
> $ ../configure --host=i686-gnu CC='gcc -m32'
I usually c
ng line at the end:
gnumach-test-success-and-reboot: test module-task exit code 0
Keep us updated of how it goes :)
Cheers,
Diego
Hello,
On Sat, May 31, 2025 at 09:32:21PM +0100, Diego Nieto Cid wrote:
>
> I'll try to attach gdb to the connecting socat to see if I can find
> where it's hanging. But if something rings a bell (like /dev/null usage
> maybe) I'm all ears :)
>
I attach t
x-children=1,backlog=128 \
STDOUT
# Connecting side
demo@debian:~/dev/tests/util-linux/socat$ socat \
-u /dev/null \
UNIX-CONNECT:./socket,retry=30,interval=0.1
(hangs)
On Linux, on the other hand, the connecting side return with 0 exit code:
# Listening side
die
75d3bd74a4e
[2]
https://sourceware.org/git/?p=glibc.git;a=commit;h=919bf1489abe634aefbcf3532617e7c5987c56ab
Thnaks,
Diego
Hello,
On Tue, May 27, 2025 at 02:48:47AM +0100, Diego Nieto Cid wrote:
>
> That seems to be it. I've checked out the branch relase/2.41/master and now
> make check is going further with no `Killed` output.
>
Well, it finally failed :(
gcc -o /home/demo/dev/hurd/upstrea
Hello,
On Tue, May 27, 2025 at 01:38:07AM +0100, Diego Nieto Cid wrote:
>
> Is master supposed to work or should I check some more stable branch?
>
That seems to be it. I've checked out the branch relase/2.41/master and now
make check is going further with no `Killed` ou
xz
[2] git://sourceware.org/git/glibc.git
--
Diego
ean
VM and glibc source tree, although I don't think my changes make any difference.
--
Diego
figure only with the prefix option, like below:
demo@debian:~/dev/hurd/upstream/glibc-build$ ../glibc/configure
--prefix=/usr
I'm not sure whether I need to specify other options, too.
--
Diego
Hello,
On Thu, May 22, 2025 at 02:44:28AM +0200, Samuel Thibault wrote:
> Diego Nieto Cid, le mer. 21 mai 2025 23:57:26 +0100, a ecrit:
> > Now I have a few issues building GLIBC.
> >
> > 1. I added the following checks to sysdeps/mach/configure.ac
> >
> >
make: *** [Makefile:36: install] Error 2
demo@debian:~/dev/hurd/upstream/glibc-build$ ls
Killed
Do I need to apply some patch/es to the sourceware repository for Hurd?
Thanks,
Diego
Hello,
On Tue, Feb 04, 2025 at 09:33:47PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le ven. 10 janv. 2025 19:40:05 +0100, a ecrit:
> > Diego Nieto Cid, le mar. 07 janv. 2025 18:48:49 +, a ecrit:
> > > I've been running gnumach with this patch for some time, do
he message says
`unknown error` after all :-) But aligning to what GNU/Linux does would
help the porting to be easier.
What should we do here?
Regards,
Diego
--
[1]
https://github.com/abseil/abseil-cpp/blob/master/absl/base/internal/strerror_test.cc#L41
[2] https://pubs.opengroup.org/onlinepubs/9799919799/functions/strerror.html
On Tue, Jan 21, 2025 at 01:02:12AM +0100, Samuel Thibault wrote:
>
> Sorry for the back&forth, we couldn't know before trying.
>
No problem, I'll drop this patch then.
Thanks
Hi,
On Fri, Jan 10, 2025 at 07:40:05PM +0100, Samuel Thibault wrote:
>
> Probably ext2fs doesn't really cope well with memory allocation
> limitation?
>
That's a good candidate, indeed. I replaced the prinf with a panic call, but
I couldn't reproduce the error, yet.
Diego
Hi,
On Thu, Jan 09, 2025 at 11:51:27AM +0300, Sergey Bugaev wrote:
>
> "Implementer", "architecture", "variant", "part", "revision" come from
> midr/revidr [0], and "features" are hwcap names. These are privileged
> registers that only EL1 can read, but on AArch64 gnumach, their values
> are obta
Hi,
On Wed, Jan 08, 2025 at 10:25:41AM +0100, Luca wrote:
>
> Il 08/01/25 02:30, dnie...@gmail.com ha scritto:
> > From: Diego Nieto Cid
> >
> > Beside that, I probably need to cache the CPUID provided information
> > as I don't think it would change over
ck whether corruption
appears again.
If the memory limitation is the culprit, I should probably enter the debugger,
if present, as soon as an allocation is denied. I got to find out how to do
that, though. In such way, I hope to find the task that is failing.
Thanks
--
Diego
k_t task = current_task();
> + printf("[%s] [task %s] map size: %lu, none: %lu, requested:
> %lu, limit: %lu\n",
> + fn_name, task->name, map->size, map->size_none, size,
> map->size_cur_limit);
Should I drop the printf here now that vm_map_print also prints this
information?
--
Diego
On Wed, Jan 01, 2025 at 10:11:24PM +0100, Samuel Thibault wrote:
> Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > > /* Structure used for storage of ancillary da
On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > >
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghd
On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> >
> > /* Structure used for storage of ancillary data object information. */
> > struct cmsghdr
> > {
> > socklen_t cmsg_len; /* Length of data in cmsg_data plus
> > length
> >
On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
>
> Adding the following line to the program:
>
> printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
>
> shows 12 on Hurd and 16 on Linux. I think I'm closer :)
The only difference in the str
On Tue, Dec 31, 2024 at 08:25:00PM +, Diego Nieto Cid wrote:
> On Tue, Dec 31, 2024 at 04:01:08PM +0000, Diego Nieto Cid wrote:
> >
> > Ok, I'll have a look in both OSes behaviour.
>
> There's something wrong with our CMSG_DATA macro. It produces the wrong
On Tue, Dec 31, 2024 at 04:01:08PM +, Diego Nieto Cid wrote:
>
> Ok, I'll have a look in both OSes behaviour.
There's something wrong with our CMSG_DATA macro. It produces the wrong
output (or at least different from Linux).
The attached program prints:
cmsg: 0
Hi,
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
>
> You should probably check precisely the difference between Linux and
> Hurd on these alignment questions at the various stages.
>
I placed a `g_message` call in `g_unix_credentials_message_deserialize` and
on Linux it does
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le mar. 31 déc. 2024 14:36:02 +0100, a ecrit:
> > > I'm not sure how to fix it. Should the expectations of GLib be updated
> > > to be aligned? Like below:
> > >
> > > - if (size != G_CREDENTIALS_NATIVE_SIZE)
> > >
On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
>
> Here are the results for `hurd-amd64`:
>
> $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \
>
On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
>
> See the error test, it's about G_CREDENTIALS_NATIVE_SIZE, see its
> definition:
>
> #define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct cmsgcred))
>
> And the definition of struct cmsgcred in bits/socket.h
>
I wrote a little tes
Hi,
On Mon, Dec 30, 2024 at 07:08:55PM +0100, Samuel Thibault wrote:
>
> Please also add printing size_null in vm_map_print.
>
Ok
> dnie...@gmail.com, le mer. 25 déc. 2024 16:16:06 -0300, a ecrit:
>
> > @@ -1679,11 +1747,13 @@ kern_return_t vm_map_protect(
> > vm_map_clip_end(map,
On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
> Hello,
>
> Diego Nieto Cid, le dim. 29 déc. 2024 22:14:40 +, a ecrit:
> > (ibus-daemon:17123): GLib-GIO-WARNING **: 20:49:29.230: Expected a
> > credentials
> > struct of 84 byt
pplied for hurd-amd64[2]:
* add t64 suffix to libgtk-3-0 directory where the query immodules binary is
found
* replace `&> file` redirection to the more standard `> file 2>&1` understood
by dash
Anybody has a hunch on the culprit?
Thanks,
Diego
---
[1]
https://gitlab.gnom
Hi,
Well, the holidays salutation message ended up as commit message unexpectedly.
I guess for review it's ok. But I need to fix it before it's ready for commit.
:(
On Tue, Dec 24, 2024 at 02:11:07PM -0300, Diego Nieto Cid wrote:
>
> I've been expanding the comment in gnumach.defs:
>
> /*
> * Set a task virtual memory limit parameters
> *
> * HOST_PORT must be the privileged host control port
>
On Tue, Dec 24, 2024 at 12:44:49PM +0300, Sergey Bugaev wrote:
> > + ASSERT(err == KERN_SUCCESS, "cannot set VM limits");
>
> There's ASSERT_RET, which also stringifies the error code.
>
Good, that's much better.
> > + /* check limits are actually saved */
> > + err = vm_get_size_limit(mac
On Mon, Dec 23, 2024 at 10:11:10AM +0300, Sergey Bugaev wrote:
> > +
> > + vm_map_lock(parent_task->map);
> > + vm_map_copy_limits(parent_task->map, new_task->map);
> > + vm_map_unlock(parent_task->map);
>
> Should this instead be done as a part of vm_map_
On Mon, Dec 23, 2024 at 10:09:35AM -0300, Diego Nieto Cid wrote:
> >
> > No, this would lock/unlock the map twice. Rather see if you can do the
> > check after the map is already locked, perhaps right before "See
> > whether we can avoid creating a new entry
Hello,
On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
>
> To experiment I'd suggest creating a test program as the ones in the tests/
> folder in gnumach source, so you can try every single case and easily debug
> it. Currently they can only be run on GNU/Linux as they require qemu.
>
I'v
to address is how to enforce the ability to change this limit,
> > e.g. an unprivileged task shouldn't be able to increase its own memory
> > limit. You could reuse the host privileged port, but maybe it could make
> > sense to have a dedicated one for resource limits?
&g
a matter
of time until the PR is merged?
--
Diego
uxFutex.cpp:31:10: fatal error: linux/futex.h: No such file
or directory
31 | #include
Do we have futexes?
--
Diego
Hi,
On Sat, Dec 21, 2024 at 10:06:10PM +0300, Sergey Bugaev wrote:
>
> In case you don't realize, there's more than one kernel map.
> kernel_map is the main one, but there are also ipc_kernel_map and
> device_io_map, which are submaps of kernel_map, and others could
> potentially be added.
>
> T
Hello,
On Fri, Dec 20, 2024 at 12:18:36PM +0300, Sergey Bugaev wrote:
> On Thu, Dec 19, 2024 at 6:56 PM Diego Nieto Cid wrote:
> > I thought of adding an RPC call that sets the `hard_limit` field
> > which, I guess, should be located among the other task related RPCs.
>
>
Hi,
On Fri, Dec 20, 2024 at 10:25:02AM +0100, Luca wrote:
>
> are you working on x86_64? if yes, that could be the redzone configured
> here:
>
> https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/exec/exec.c#n1247
>
Yes I'm on x86_64, it looks like that's the allocation.
>
> I think the on
Hi,
I've been testing RLIMIT_DATA...
On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
>
> I see that some limits (e.g. RLIMIT_DATA) are managed in glibc instead of
> gnumach, maybe this could be a simpler way to add some minimal support? I
> guess that one might overcome these limits by usi
On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
>
> I see that some limits (e.g. RLIMIT_DATA) are managed in glibc instead of
> gnumach, maybe this could be a simpler way to add some minimal support? I
> guess that one might overcome these limits by using directly the mach rpc or
> hijacking
Hello,
After playing a bit with the setrlimit calls in Linux to see how the
resource RLIMIT_AS actually works, it seems to be limiting the amount
of virtual memory available to the process (and not the available
virtual address range).
So, I'm attempting to implement this limit in gnumach at the
El mar, 17 dic 2024 a las 23:33, Zhaoming Luo ()
escribió:
> On 12/18/24 10:02 AM, Diego Nieto Cid wrote:
> > El mar, 17 dic 2024 a las 22:21, Zhaoming Luo ()
escribió:
> >
> > `read_elapsed_ticks` is only used to calculate elapsed_usec and thus
> > may be inlined, re
El mar, 17 dic 2024 a las 22:21, Zhaoming Luo () escribió:
>
> The precision of this implmentation is 10ms. Not sure how to do with the
> possible data race.
>
> Signed-off-by: Zhaoming Luo
> ---
> include/mach/mach_host.defs | 7 +++
> kern/mach_clock.c | 20
>
I can confirm that with the zero store patch applied libzstd tests run
successfully \o/
It takes a long time though, time reports:
real151m26.790s
user0m0.020s
sys 0m0.010s
There are two tests that outputs great amounts of data (~4GB) into a
temporary file, then md5sum i
El mar, 10 dic 2024 a las 8:41, Diego Nieto Cid () escribió:
>
> Is this a known issue? (besides bug 43320 which involves a child process [1])
>
Ok, I just found this comment in `sysdep/mach/hurd/setrlimit.c`:
/* Even though most limits do nothing, there is no inheritance,
malloc call fails and returns NULL, then the program
goes on and get a SEGFAULT (weird way of testing things :/ )
>8>8
(gdb) run
Starting program: /home/diego/dev/hurd/zzuf/tests/bug-memory
[Thread debugging using libthread_db enabled]
Using host libthread_db library "
Hi,
This is weird, just run the build, twice, and no test failed. It's
probably caused by some temporary state of the buildd.
Can we attempt a build again?
Thanks
Hey Sergey,
Thanks for making sense of my gibberish :-)
So, once the fix lands in hurd/glibc packages we can drop the debian
patch and fix upstream (libzstd)
Here is some stacktrace.
--->8>8
(gdb) frame
#0 _hurd_fd_write (fd=fd@entry=0x1012dde10,
buf=buf@entry=0x2dd0, nbytes=nbytes@entry=0x10103da78,
offset=offset@entry=-1)
at ./hurd/fd-write.c:39
39 *nbytes = wrote;
(gdb) bt
#0 _hurd_fd_write (fd=fd@entry=0x1012dde10
El mar, 3 dic 2024 a las 22:50, Diego Nieto Cid () escribió:
>
> Also, it's quite difficult without the source code. I've downloaded
> glibc-source and extracted the tar.xz. How do I instruct gdb to use
> those files?
>
GDB's directory command helped in this front. I'll continue debugging :-)
El mar, 3 dic 2024 a las 18:33, Samuel Thibault
() escribió:
>
> And nothing else after that? fclose() would need to be run inside gdb to
> make sure where exactly it returns an error. Possibly it's simply
> _IO_do_flush that doesn't work for /dev/zero, but this doesn't show up
> in the RPCs above.
El mar, 3 dic 2024 a las 18:55, Samuel Thibault
() escribió:
>
> Maybe check how your /etc/adjtime is configured (see man hwclock),
> against how virtualbox considers the RTC time should be set.
>
/etc/adjtime says UTC and VirtualBox uses Local Time (Windows host).
But there's a switch to flip, so
BTW, the /dev/zero holds the following translator entry:
$ showtrans /dev/zero
/bin/nullauth -- /hurd/storeio -Tzero
I'm having a hard time finding the code handling the "-Tzero"
parameter. But, from a quick look at the arguments of storeio, it is
readonly by default. Maybe that has somet
El mar, 3 dic 2024 a las 17:15, Samuel Thibault
() escribió:
>
> Oh, that's odd indeed. Perhaps run it through rpctrace to see what
> happens behind.
>
I attached the rpctrace log. I'm not sure what to look for but the
following lines seem relevant:
7<--38(pid1044)->dir_lookup ("dev/zero" 655
El mar, 3 dic 2024 a las 12:47, Samuel Thibault
() escribió:
>
> Yes, the current behavior is really odd, I don't see why zstd would try
> to remove /dev/zero...
>
I managed to craft a small reproducer by doing the following steps:
1. open /dev/zero
2. write something into it
3. close it
H
El mar, 3 dic 2024 a las 11:54, Samuel Thibault
() escribió:
>
> Diego Nieto Cid, le mar. 03 déc. 2024 11:47:08 -0300, a ecrit:
> > El mar, 3 dic 2024 a las 11:26, Samuel Thibault
> > () escribió:
> >
> > INTOVOID="/dev/null"
> > case &qu
El mar, 3 dic 2024 a las 11:26, Samuel Thibault
() escribió:
>
> Diego Nieto Cid, le mar. 03 déc. 2024 11:10:57 -0300, a ecrit:
> > which produce the following piece of logs:
> >
> > $ cat tests/tmplog
> > + '[' -z '' ']'
> &g
Hello,
I was looking at the buildd failures of libzstd to try to fix it. It
compiles fine but one of the tests (so far...) fails to run
properly[1]:
test : should quietly not remove non-regular file
make[2]: *** [Makefile:352: test-zstd] Error 1
make[2]: Leaving directory '/<>/tests'
Hello again,
Nevermind, I had to also set the date with `date -s ""`. It seems
only changing the timezone is not enough as the time is not fixed.
Thanks
El lun, 2 dic 2024 a las 23:23, Diego Nieto Cid ()
escribió:
> Hello,
>
> So it seems I cannot run `sudo apt update` afte
alid for another 2h 3min 33s). Updates for this repository will not
be applied.
>8-->8
Did I miss something? Is it VirtualBox's fault?
Regards,
Diego
---
[1]
https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/debian-hurd.img.tar.xz
[2] https://cd
Hello
>--- /dev/null
>+++ pam-1.5.3/libpam/include/path_max.h
>@@ -0,0 +1,7 @@
>+/*
>+ * Define PATH_MAX if not available
>+ */
>+
>+#ifndef PAH_MAX
There's a typo here ^
>+#define PATH_MAX 4096
>+#endif
Cheers
Hello,
El dom, 14 ene 2024 a las 23:35, jbra...@dismail.de ()
escribió:
> + tmpfs rocks!
> +$
> \ No newline at end of file
>
I'm not sure what the policy is for the Wiki but this kind of diff message
should be
avoided by inserting a newline at the end of the file. :-)
Cheers
Hi
El mié, 24 may 2023 a las 15:43, jbra...@dismail.de ()
escribió:
> +
> +New test to see if the rump kernel works before you make the change
> +permanent. Manually tweak your /boot/grub/grub.cfg like so:
>
Should that read "Now test" instead of "New test"?
Cheers!
fix from xkb_base and then
"prepend" the prefix passed to configure. I'm not sure how robust it is
though.
---
Diego
Hello,
One more update.
On Wed, Apr 13, 2016 at 10:58:18PM -0300, Diego Nieto Cid wrote:
>
> So, it looks like '_hurd_intr_rpc_mach_msg' is not being corretly
> resolved in the loader's code, right? Although, I'm puzzled about why
> all the previous messages were
yway, this is purely a cosmetic issue affecting only the output produced
by the LD_DEBUG feature of the dynamic linker. At least, I'm not aware of
any other glitches caused by this issue.
It's probably a very low priority issue then. (that output being correct
would be nice though :)
Regards,
Diego
So, it looks like '_hurd_intr_rpc_mach_msg' is not being corretly
resolved in the loader's code, right? Although, I'm puzzled about why
all the previous messages were printed successfully.
Another behaviour I noticed, and which may be related, is that after
getpid is bound the
normal symbol `__mach_msg'", dataCnt=115,
offset=-1,
amount=0x2d80c)
at
/opt/stash/diego/src/debian/glibc/glibc-2.22/build-tree/hurd-i386-libc/hurd/RPC_io_write.c:140
#1 0x0001780a in __writev (fd=, iov=,
niov=) at ../sysdeps/mach/hurd/dl-sysdep.c:429
#2 0x
Hi,
Here are the stack traces:
=> LD_DEBUG=bindings
On Tue, Mar 15, 2016 at 10:30:07PM +0100, Samuel Thibault wrote:
> Hello,
>
> Diego Nieto Cid, on Sun 13 Mar 2016 18:28:46 -0300, wrote:
> > => 0x0001052b <_dl_start_profile+235>: mov%eax,-0x24
buf, total, -1, &nwrote);
if (err)
return __hurd_fail (err);
-
+*/
return nwrote;
}
return 0;
then the loader/program no longer crashes.
Thanks,
Diego
Hi
On Mon, Mar 07, 2016 at 08:45:59PM -0300, Diego Nieto Cid wrote:
>
> I'm not sure what's going on. I've made some simple tests trying
> to imitate the setup but weak symbols were correctly overriden.
>
Well, this is weird. I added a call to cthread_getspecific t
Hi
Here's another iteration of the patch. __libc_getspecific now
considers the case were pthread is not loaded except when the
containing file is being compiled for the loader.
The test case, when built without pthread, now works
approprietly:
diego@hird:~/src/test-cases/dlopen-
function as it is, is that by calling cthread_getspecific
it forces dlerror to clobber errno; and then the console client is in trouble.
May I do as below?
void *val = NULL;
if ( _cthread_init_routine)
cthread_getspecific (key, &val);
return val;
Thanks,
Diego
[0]
0: symbol=realloc; lookup in
file=/home/diego/src/debian/glibc/glibc-2.21/build-tree/hurd-i386-libc/libc.so.0.3
[0]
0: binding file /lib/ld.so [0] to
/home/diego/src/debian/glibc/glibc-2.21/build-tree/hurd-i386-libc/libc.so.0.3
[0]: normal symbol `realloc
ual
message given by dlerror.
Thus, console-client is relying on undefined behaviour. Unfortunately,
it seems the only standard way is to parse that textual message. :-(
I guess console-client could be modified to try other directories in the
search path regardless of the reason why dlopen failed.
Diego
On Sun, Feb 28, 2016 at 10:43:04AM +0100, Samuel Thibault wrote:
> Esa Peuha, on Sun 28 Feb 2016 11:00:07 +0200, wrote:
>
> > The attachment is the entire output of git format-patch; I think it's
> > the best I can do when using Gmail to send mail.
>
> That will work fine, but it'll be tedious fo
ource, dlerror.c file, there's nothing that
could be labeled as unimplemented, at a first glance; just calls to
things like asprintf, strcmp and free.
Any ideas?
Regards,
Diego
--
P.S. I stumbled upon this issue by following the advice in
/etc/defaults/hurd-console of setting KBD to "-d xkb&
2015-11-04 16:03 GMT-03:00 Svante Signell :
> On Wed, 2015-11-04 at 18:57 +0100, Samuel Thibault wrote:
> > Diego Nieto Cid, on Wed 04 Nov 2015 10:50:35 -0300, wrote:
> > > assert (__hurd_local_reply_port == arg || arg == MACH_PORT_NULL)
> > >
> > > AIUI
Hi
2015-11-04 6:30 GMT-03:00 Svante Signell :
>
> Diego,
> Cc: bug-hurd.
Oh, I mistakenly hit 'Reply'. I hate when that happens :(
> On Tue, 2015-11-03 at 15:55 -0300, Diego Nieto Cid wrote:
>
> > I'd suggest to assert (port == arg || arg == MACH_PORT_N
2015-09-17 12:35 GMT-03:00 Samuel Thibault :
> Diego Nieto Cid, le Thu 17 Sep 2015 12:25:21 -0300, a écrit :
>> In that way there are several sound related translators separating the
>> concerns
>> while the hardwarde is still accessed by a single translator avoiding th
2015-09-16 20:06 GMT-03:00 Samuel Thibault :
> Diego Nieto Cid, le Wed 16 Sep 2015 22:12:19 +, a écrit :
>> Except for how to know which one the send right was obtained from in
>> the translator when a message from a client comes?
>
> term is probably easier to ha
Hi
El mié., 16 sept. 2015 a las 17:57, Robert Millan () escribió:
> The other problem I had is that I don't know how to make a single
> translator
> service two separate device nodes (obviously you don't want to start a
> different Rump instance for /dev/audio, /dev/mixer, etc as they would fight
Hi
Sorry, I meant to send this to the list too but failed to do so.
El sáb., 29 de agosto de 2015 17:58, Robert Millan escribió:
El 29/08/15 a les 21:56, Diego Nieto Cid ha escrit:
>
>
> Hi
>
>
> El sáb., 29 de agosto de 2015 16:37, Robert Millan > escribió:
>
>
&g
El mar., 18 ago. 2015 a las 23:20, Diego Nieto Cid ()
escribió:
> This is the first patch to the web I make and being the edit function down
> I don't know how to test it :(
>
Nevermind, I've found the relevant documentation in the wiki :)
1 - 100 of 178 matches
Mail list logo
