On Sat, Apr 15, 2023 at 9:45 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote:
> Sergey Bugaev, le ven. 14 avril 2023 23:29:51 +0300, a ecrit:
> > By the way: that __mig_dealloc_reply_port () inside
> > _dl_sysdep_start_cleanup () is not doing what the author of that code
> > wanted it to do. It deallocates the current reply port, but while
> > doing that, it creates a fresh one in its place.
>
> You mean with the __mach_port_deallocate calls?
Heh, well those actually too, but I didn't even think of that. We
can't deallocate the reply port before the task, but we can't do it
the other way around either -- fun!
What I meant was __mig_dealloc_reply_port itself ends up creating a
new port for the __mach_port_mod_refs RPC. Which is fine: the semantic
of __mig_dealloc_reply_port is "the current reply port (also passed as
an argument) might be broken, do something about it". If you really
want to deallocate and reset the current reply port, you need to do
the dance like sigreturn does:
mach_port_t reply_port = THREAD_GETMEM (THREAD_SELF, reply_port);
THREAD_SETMEM (THREAD_SELF, MACH_PORT_DEAD);
(void) __mach_port_mod_refs (... reply_port ...);
THREAD_SETMEM (THREAD_SELF, MACH_PORT_NULL);
> > It would be nice to not deallocate __mach_{task,host}_self_ too, and
> > instead migrate them into the new libc.so slots.
>
> That'd need different variables names, but that should be doable easily
> by redirecting __mach_task_self in mach_init.h dependening on building
> ld.so.
I think we could look the symbols up in libc.so explicitly, like it's
done for malloc in __rtld_malloc_init_real. But we could also do
__rtld_mach_task_self_ + weak __mach_task_self_ as you're saying.
> > Besides, are we 100% sure that after initially entering libc.so, ld.so
> > will never do any Mach things (RPCs) anymore?
>
> AIUI all the OS-dependent things that ld.so calls comes from
> dl-sysdep.c, so as long as all these are weak functions, we're safe.
But how can we be sure of this?
In fact, this is demonstrably false. elf/dl-profile.c calls __profil,
which pulls sysdeps/mach/hurd/profil.c into rtld, and various other
crap (threading...) along with it.
Yes, I still can't get over the fact that rtld is implicitly pulling
out object files from libc. Even if there's no explicit #include
<mach.h> in rtld.c, it can still reference things that have
system-specific implementations. And who knows how much of the libc
proper this pulls in! Well, you can't know unless you review
elf/librtld.os.map.
Maybe there should be a build step that checks that nothing unexpected
gets pulled in, and that nothing system-dependent is ever accessed
other than through dl-sysdep.
Think of it this way: the compiler can always decide to insert calls
to memcpy even when there are none in the source code (unless we build
with -ffreestanding, which we don't), and memcpy may have a
system-specific implementation (think vm_copy / PAGE_COPY_THRESHOLD).
So we cannot even verify this based on any analysis of the source
code, we need this to be a post-compilation build step.
Sergey
