On Sat, Apr 22, 2023 at 2:17 PM Luca Dariz <l...@orpolo.org> wrote: > Hi Sergey,
Hi, > Il 20/04/23 13:51, Sergey Bugaev ha scritto: > > On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev <buga...@gmail.com> wrote: > > We do reach the call to __thread_set_state (), but then it uses > > __mig_memcpy (), which is just 'return memcpy (...)'. And (because of > > the static build?), that memcpy () is the full real ifunc-selected > > memcpy. So it jumps to the memcpy@plt, which jumps to > > *(mem...@got.plt), which is supposed to jump into the rtld and then > > run the ifunc resolver and do its smarts and eventually jump to the > > right memcpy... > > I don't know if you already found a good solution for this, but if not > maybe we could add an x86_64-specific plain syscall to set fsbase/gsbase > during bootstrap, if it can make things more manageable. Thank you, but that won't help much, since thread_set_state is not the only offender, there are more memcpy/memmove calls further (in RPC_exec_startup_get_info and hurdstartup.c). So we need to solve this in userspace one way or another. My pre-filling GOT thing seems to work well, although it hasn't received any positive feedback from glibc maintainers. Alternatively we could use Adhemerval Zanella Netto's suggestion to redirect memcpy to a baseline implementation in some .c files at compile time. Rather, please look into why device_write () hangs in ast_taken (), and into enabling > 4 GB address space, and into the crash when not using console=com0. Once you figure out the hang in device_write (), I'd like to experiment with building and running some REPL -- like maybe Python or Bash or some Lisp; but it needs to work without forking (so Bash wouldn't really work...) and without accessing any files (Python wants to load its stdlib from the fs I believe). So please suggest your favorite REPL :) Sergey
