On 2025-05-20 15:50, Michael Tokarev wrote:
07.02.2025 18:31, Alex Bennée wrote:
From: Ilya Leoshkevich <i...@linux.ibm.com>

In case an emulated process execve()s another emulated process, bind()
will fail, because the socket already exists. So try deleting it. Use
the existing unix_listen() function which does this. Link qemu-user
with qemu-sockets.c and add the monitor_get_fd() stub.

Note that it is not possible to handle this in do_execv(): deleting
gdbserver_user_state.socket_path before safe_execve() is not correct,
because the latter may fail, and afterwards we may lose control.

Please note: this is linux-user stuff, which is usually linked statically. By linking it with qemu-sockets, we basically broke static linking, because qemu-sockets uses getaddrinfo() &Co. The previous code, I think, was there
for a reason, - to avoid this linkage.

How do you think about reverting this one and addressing the original
problem without using qemu-sockets?

Alternatively, it might be possible to split qemu-sockets.c into unix-related
stuff and generic stuff.

Thanks,

/mjt

I can split it.

However, wasn't it already broken in this regard?
With fccb744f41c69fec6fd92225fe907c6e69de5d44^ I get:

[2/2] Linking target qemu-s390x
/usr/bin/ld: /usr/lib64/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': (.text+0xeb): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0x2be): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: (.text+0x134): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This comes from glib, but the ultimate result is still the same.

Also, what are the symptoms of the breakage? IIUC as long as execution
does not reach getaddrinfo(), which it in this case should not, because
it is used only on inet paths, there should not be any issues, right?

In any case, the new warning is annoying and I better fix it for this
reason alone.

Reply via email to