Re: [PATCH v2 11/17] gdbstub: Try unlinking the unix socket before binding

[Ilya Leoshkevich <iii@linux.ibm.com>]

On 2025-05-20 15:50, Michael Tokarev wrote:
> 07.02.2025 18:31, Alex Bennée wrote:
>> From: Ilya Leoshkevich <iii@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.