- Subject: glibc-2.1: sigstack doesn't work
- From: Various
- Date: Sun Apr 18 12:46:42 1999
Topics:
glibc-2.1: sigstack doesn't work
Re: glibc-2.1: sigstack doesn't work
Re: glibc-2.1: sigstack doesn't work
----------------------------------------------------------------------
Date: Sat, 17 Apr 1999 19:26:36 +0200
From: Urs Thuermann <urs@isnogud.escape.de>
To: glibc-linux@ricardo.ecn.wfu.edu
Subject: glibc-2.1: sigstack doesn't work
Message-Id: <199904171726.TAA18385@isnogud.escape.de>
The following program
int main()
{
if (sigstack(0,0) < 0)
perror("foo: sigstack");
return 0;
}
prints "foo: sigstack: Function not implemented", i.e. the sigstack()
function return with ENOSYS.
I've spent an hour or so finding the reason, but got stuck.
I've commpiled --with-headers=/usr/src/linux-2.2.5/include, and since
./asm-i386/unistd.h defines
#define __NR_sigaltstack 186
the sigstack() function in glibc-2.1/sysdeps/unix/sysv/linux/sigstack.c
should be compiled as a wrapper around __sigaltstack(). I believe
this is true because when linking the above test program I indeed get
the
link_warning (sigstack, "the `sigstack' function is dangerous...")
defined in glibc-2.1/sysdeps/unix/sysv/linux/sigstack.c and also,
__stub_sigstack
is not defined in <gnu/stubs.h>, which autoconf usually tests for
AC_CHECK_FUNCS(sigstack).
I don't understand, however, where __sigaltstack() is implemented.
grepping for it through the whole glibc-2.1 src, I only found
./sysdeps/unix/sysv/linux/syscalls.list:sigaltstack - sigaltstack 2 __sigaltstack sigaltstack
suggesting to me, that it is the real system call. But strace'ing the
test program did not show this sys call but only the write() to
stderr.
What am I missing here?
I found this when recompiling GNU m4-1.4 today. Its configure script
checks for sigstack and sigaltstack and find both, i.e. the
__stub.*sigstack symbols seem not to be defined. The GNU m4 uses then
sigstack() instead of sigaltstack() because it doesn't find
<siginfo.h>.
There is a <bits/siginfo.h> but no <siginfo.h>. Is that intended?
urs
------------------------------
Date: 17 Apr 1999 22:37:35 +0200
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Urs Thuermann <urs@isnogud.escape.de>
Cc: glibc-linux@ricardo.ecn.wfu.edu
Subject: Re: glibc-2.1: sigstack doesn't work
Message-ID: <u8btgnc7ao.fsf@arthur.rhein-neckar.de>
References: <199904171726.TAA18385@isnogud.escape.de>
Content-Type: text/plain; charset=us-ascii
>>>>> Urs Thuermann writes:
Urs> The following program
Urs> int main()
Urs> {
Urs> if (sigstack(0,0) < 0)
Urs> perror("foo: sigstack");
Urs> return 0;
Urs> }
Urs> prints "foo: sigstack: Function not implemented", i.e. the sigstack()
Urs> function return with ENOSYS.
Urs> I've spent an hour or so finding the reason, but got stuck.
Urs> I've commpiled --with-headers=/usr/src/linux-2.2.5/include, and since
Urs> ./asm-i386/unistd.h defines
Urs> #define __NR_sigaltstack 186
Urs> the sigstack() function in glibc-2.1/sysdeps/unix/sysv/linux/sigstack.c
Urs> should be compiled as a wrapper around __sigaltstack(). I believe
Urs> this is true because when linking the above test program I indeed get
Urs> the
Urs> link_warning (sigstack, "the `sigstack' function is dangerous...")
Urs> defined in glibc-2.1/sysdeps/unix/sysv/linux/sigstack.c and also,
Urs> __stub_sigstack
Urs> is not defined in <gnu/stubs.h>, which autoconf usually tests for
Urs> AC_CHECK_FUNCS(sigstack).
Urs> I don't understand, however, where __sigaltstack() is implemented.
Urs> grepping for it through the whole glibc-2.1 src, I only found
Urs> ./sysdeps/unix/sysv/linux/syscalls.list:sigaltstack - sigaltstack 2 __sigaltstack sigaltstack
Urs> suggesting to me, that it is the real system call. But strace'ing the
Urs> test program did not show this sys call but only the write() to
Urs> stderr.
Urs> What am I missing here?
Urs> I found this when recompiling GNU m4-1.4 today. Its configure script
Urs> checks for sigstack and sigaltstack and find both, i.e. the
Urs> __stub.*sigstack symbols seem not to be defined. The GNU m4 uses then
Urs> sigstack() instead of sigaltstack() because it doesn't find
Urs> <siginfo.h>.
Are you running a 2.0 kernel or a 2.2.5 kernel? sigaltstack isn't
implemented on 2.0 and therefore should returns ENOSYS. If this is
really your problem, I've to investigate a wee bit. Please give us
some more details about your environment.
Urs> There is a <bits/siginfo.h> but no <siginfo.h>. Is that intended?
<bits/siginfo.h> has:
#if !defined _SIGNAL_H && !defined __need_siginfo_t
# error "Never include this file directly. Use <signal.h> instead"
#endif
Andreas
- -
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sun, 18 Apr 1999 04:19:59 +0200
From: Urs Thuermann <urs@isnogud.escape.de>
To: glibc-linux@ricardo.ecn.wfu.edu
Subject: Re: glibc-2.1: sigstack doesn't work
Message-Id: <199904180219.EAA24100@isnogud.escape.de>
References: <199904171726.TAA18385@isnogud.escape.de> <u8btgnc7ao.fsf@arthur.rhein-neckar.de>
aj> Are you running a 2.0 kernel or a 2.2.5 kernel? sigaltstack isn't
aj> implemented on 2.0 and therefore should returns ENOSYS. If this is
aj> really your problem, I've to investigate a wee bit. Please give us
aj> some more details about your environment.
Yes, I'm sorry I forgot that. I'm running still 2.0.36 since I
haven't yet found the time to resolve my problems with 2.2.x and the
serial ports, causing xntpd to fail, which I really don't want to
miss.
But I still don't fully understand what's happing here. Because of
the --with-header=/usr/src/linux-2.2.5/include (as suggested in FAQ
1.8) the glibc-2.1 assumes I have sigaltstack because of the
definition of _NR_sigaltstack in unistd.h. Thus, sigstack() is
emulated by really calling __sigaltstack(), but why don't I see that
in strace? Is it maybe that strace doesn't show anything for system
call to the kernel it doesn't know?
Otherwise it would mean that glibc never tries to call the
sigaltstack() system call, although configured with the 2.2.5 headers.
I just tried to call sigaltstack() directly, ith the same result:
return value is ENOSYS but strace doesn't show anything for this
syscall:
$ cat foo.c
int main()
{
if (sigaltstack(0,0) < 0)
perror("foo: sigaltstack");
return 0;
}
$ strace ./foo
...
personality(PER_LINUX) = 0
getpid() = 23880
write(2, "foo: sigaltstack: Function not i"..., 43foo: sigaltstack: Function not implemented
) = 43
_exit(0) = ?
In any case, either the glibc stub for sigaltstack() itself returns
ENOSYS or it calls the kernel which the returns with ENOSYS with
strace not showing this call. I tend to believe the latter since in
gdb I disassembled sigaltstack
(gdb) disas sigaltstack
Dump of assembler code for function __sigaltstack:
0x400362c0 <__sigaltstack>: movl %ebx,%edx
0x400362c2 <__sigaltstack+2>: movl 0x8(%esp,1),%ecx
0x400362c6 <__sigaltstack+6>: movl 0x4(%esp,1),%ebx
0x400362ca <__sigaltstack+10>: movl $0xba,%eax
0x400362cf <__sigaltstack+15>: int $0x80
showing that there is really an "int $0x80" with %eax set to 186
(_NR_sigaltstack0).
What would be the correct behavior for 2.0.x kernels? I've looked at
unistd.h of 2.0.36 and it seems that it has neither sigstack nor
sigaltstack. So probably autoconf configure scripts like that for m4
should not see sigstack or sigaltstack available. But how can glibc
do this, since it doesn't know that the binary to be configured and
compiled should run on a 2.0.x kernel? Is it really that good an idea
to use the 2.2.5 headers when running the resulting libc on a 2.0.x
kernel?
I don't see how glibc could behave correctly, if it is configured with
the 2.2.5 header and can't know if it will be used on a 2.2.x or a
2.0.x kernel. glibc-2.1 must install its own headers in /usr/include
so that
1. autoconf sees sigstack and/or sigaltstack, i.e. it produces
#define HAVE_SIGSTACK 1 and #define HAVE_SIGALTSTACK 1
This is wrong when running a 2.0.x kernel.
or
2. autoconf does not see sigstack and sigaltstack, i.e. it produces
#undef HAVE_SIGSTACK and #undef HAVE_SIGALTSTACK
This is wrong when running a 2.2.x kernel.
AFAICS, this can only be solved by not using --with-headers=...2.2.5...
Or is there any other behavior that could be implemented in glibc?
How is this issue solved for other sys calls that newly appeared in
2.2.x? Do the same problems exist there?
aj> #if !defined _SIGNAL_H && !defined __need_siginfo_t
aj> # error "Never include this file directly. Use <signal.h> instead"
aj> #endif
Why does GNU m4 then insist on the the existance of <siginfo.h> in
order to use sigaltstack (in case it could otherwise you sigstack)?
In m4-1.4/src/stackovf.c:
#if HAVE_SIGALTSTACK && (defined(HAVE_SIGINFO_H) || !HAVE_SIGSTACK)
/* Use sigaltstack only if siginfo is available, unless there is no
choice. */
[ use sigaltstack ]
#else
[ use sigstack ]
#endif
Gaël> I suppose you are using a 2.0 kernel, where the syscall sigaltstack
Gaël> is not implemented. So the only solution is to recompile m4 for the
Gaël> old kernel, without using sigaltstack (for example by editing
Gaël> config.cache).
I could also just unset $use_stackovf in the configure shell script.
urs
------------------------------
End of forwardrQExAx Digest
***************************