Re: strange libc symbol renaming issue
On Thu, Mar 14, 2019 at 07:51:57PM +0100, Kamil Rytarowski wrote: > > I could change sigaction to _sigaction14 in the dlsym here for NetBSD; > > is there a better way to do it ? > > > > The proper way is to call (and detect for NetBSD): __sigaction14. thanks. I ended up calling directly __libc_sigaction14(), without using dlsym(). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: strange libc symbol renaming issue
On 14.03.2019 19:30, Manuel Bouyer wrote:
> On Thu, Mar 14, 2019 at 03:14:56PM +0100, Manuel Bouyer wrote:
>> Hello,
>> I've a very strange symbol renaming issue on NetBSD 8.0/amd64:
>> syslog-ng dies with a bad syscall signal, ktrace reveals that it
>> called compat_13_sigaction13, just after properly calling __sigprocmask14.
>
>> gdb on the core dump shows:
>> Core was generated by `syslog-ng'.
>> Program terminated with signal SIGSYS, Bad system call.
>> #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12
>> (gdb) up
>> #1 0x7747b0e38f38 in g_process_perform_supervise () at
>> lib/gprocess.c:1087
>> 1087 sigaction(SIGHUP, , NULL);
>> (gdb)
>>
>> but gprocess.c properly includes signal.h, there was no warning at link time,
>> and disasembling the function confirms it:
>>0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp)
>>0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp)
>>0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp)
>>0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp)
>>0x7747b0e38f2c <+179>: xor%edx,%edx
>>0x7747b0e38f2e <+181>: mov$0x1,%edi
>>0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt>
>> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp
>>0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15
>>0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14#
>> 0x7747b0e7a2c1
>>
> Well, it turns out that sigaction is reimplemented by syslog-ng in
> lib/signal-handler.c. As it includes signal.h, its sigaction implementation
> is renamed to _sigaction14.
>
> This reimplementation of sigaction ends up calling the libc's one, using:
> static int (*real_sa)(int, const struct sigaction *, struct sigaction *);
>
> if (real_sa == NULL)
> {
> real_sa = dlsym(RTLD_NEXT, "sigaction");
> }
> return real_sa(signum, act, oldact);
>
>
> I could change sigaction to _sigaction14 in the dlsym here for NetBSD;
> is there a better way to do it ?
>
The proper way is to call (and detect for NetBSD): __sigaction14.
signature.asc
Description: OpenPGP digital signature
Re: strange libc symbol renaming issue
On Thu, Mar 14, 2019 at 03:14:56PM +0100, Manuel Bouyer wrote:
> Hello,
> I've a very strange symbol renaming issue on NetBSD 8.0/amd64:
> syslog-ng dies with a bad syscall signal, ktrace reveals that it
> called compat_13_sigaction13, just after properly calling __sigprocmask14.
> gdb on the core dump shows:
> Core was generated by `syslog-ng'.
> Program terminated with signal SIGSYS, Bad system call.
> #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12
> (gdb) up
> #1 0x7747b0e38f38 in g_process_perform_supervise () at
> lib/gprocess.c:1087
> 1087 sigaction(SIGHUP, , NULL);
> (gdb)
>
> but gprocess.c properly includes signal.h, there was no warning at link time,
> and disasembling the function confirms it:
>0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp)
>0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp)
>0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp)
>0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp)
>0x7747b0e38f2c <+179>: xor%edx,%edx
>0x7747b0e38f2e <+181>: mov$0x1,%edi
>0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt>
> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp
>0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15
>0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14#
> 0x7747b0e7a2c1
>
Well, it turns out that sigaction is reimplemented by syslog-ng in
lib/signal-handler.c. As it includes signal.h, its sigaction implementation
is renamed to _sigaction14.
This reimplementation of sigaction ends up calling the libc's one, using:
static int (*real_sa)(int, const struct sigaction *, struct sigaction *);
if (real_sa == NULL)
{
real_sa = dlsym(RTLD_NEXT, "sigaction");
}
return real_sa(signum, act, oldact);
I could change sigaction to _sigaction14 in the dlsym here for NetBSD;
is there a better way to do it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
strange libc symbol renaming issue
Hello, I've a very strange symbol renaming issue on NetBSD 8.0/amd64: syslog-ng dies with a bad syscall signal, ktrace reveals that it called compat_13_sigaction13, just after properly calling __sigprocmask14. gdb on the core dump shows: Core was generated by `syslog-ng'. Program terminated with signal SIGSYS, Bad system call. #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12 (gdb) up #1 0x7747b0e38f38 in g_process_perform_supervise () at lib/gprocess.c:1087 1087 sigaction(SIGHUP, , NULL); (gdb) but gprocess.c properly includes signal.h, there was no warning at link time, and disasembling the function confirms it: 0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp) 0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp) 0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp) 0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp) 0x7747b0e38f2c <+179>: xor%edx,%edx 0x7747b0e38f2e <+181>: mov$0x1,%edi 0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp 0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15 0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14# 0x7747b0e7a2c1 >From here gdb seems lost; I'm working on a core dump as this all happens after a fork so I can't work on it live: (gdb) disas 0x7747b0e2f700 Dump of assembler code for function __sigaction14@plt: 0x7747b0e2f700 <+0>: jmpq *0x2834a2(%rip)# 0x7747b10b2ba8 0x7747b0e2f706 <+6>: pushq $0x4e5 0x7747b0e2f70b <+11>:jmpq 0x7747b0e2a8a0 0x7747b10b2ba8 is in _GLOBAL_OFFSET_TABLE_ (gdb) x/lx 0x7747b10b2ba8 0x7747b10b2ba8: 0xb0e46527 (gdb) disas 0xb0e46527 No function contains specified address. (gdb) x/i 0xb0e46527 0xb0e46527: Cannot access memory at address 0xb0e46527 Any idea what could cause a program actually calling explicitely __sigaction14 to end up in the compat sigaction ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
