Re: someone could port libgc
> Yes, but at least the maintainer knows, (on previous packages I have been
> shouted at for this).
It is certainly important to feed back changes once they are working enough
to be of use to anyone. But it's also best not to pester maintainers with
nonworking ports that you will only be pestering them again soon to replace
with working code.
> I will try to write a test program for this. It is all part my learning
> process for Hurd and the packages it uses. Any hints gratefully
> received.
There are various things out there, such as the Bigloo Scheme system (just
do a web search for "bigloo" and you'll track down the latest one fast enough)
that use libgc and will barf all over the place if libgc is badly broken.
Getting such a real user of libgc to run its own test suites on the Hurd
would be the best test of porting libgc.
> This implies that to use libgc, every program would need, (cut from config.h):
>
> * Client code may set GC_stackbottom before calling any GC_ routines.
> * If the author of the client code controls the main program, this is
> * easily accomplished by introducing a new main program, setting
> * GC_stackbottom to the address of a local variable, and then calling
> * the original main program. The new main program would read something
> * like:
> *
> * # include "gc_private.h"
> *
> * main(argc, argv, envp)
> * int argc;
> * char **argv, **envp;
> * {
> * int dummy;
> *
> * GC_stackbottom = (ptr_t)(&dummy);
> * return(real_main(argc, argv, envp));
> * }
>
> Will this solve the problem of 'variable' stack bottom?
Yes, that would work. For multithreaded programs, something fancier needs
to be done (since there are many disjoint stacks); I imagine libgc has some
code or other to cope with other multithreaded systems (this is an issue
for almost any thread system)--though I guess it could well just be "use a
wrapper like that at the base of each thread".
There isn't any really kosher way to get the stack bounds.
There is the unreliable horrible hack approach you can see in
hurd/libthreads/stack.c::probe_stack (code we don't use).
libc gets the information from the exec server (see
libc/hurd/hurdstartup.[hc]), but doesn't save it anywhere accessible.
It does seem to me that life might be a bit easier all around if we made
the exec server try to put the stack at the top of the address space if
possible. That space will usually be available in a normal executable image.
Reply to: