I can't get the simple program below to compile on CentOS 5 beta. It compiles (and runs) just fine on CentOS 4.4, and I'm using gettid() as described in the man page. I wonder if this is a problem with RHEL 5 as well, but I don't have a system to test on. I also wonder if this is a gcc 4.1.1 issue or something missing in CentOS 5.
The issue is that the _syscall0 macro is not defined anywhere. If I copy and paste the following definition for _syscall0 from a CentOS 4.4 system into the test program, it works just fine:
#define _syscall0(type,name) \ type name(void) \ {\ return syscall(__NR_##name);\ }
Has anyone else run into this problem?
Alfred
#include <stdio.h> #include <sys/types.h> #include <linux/unistd.h> #include <errno.h>
_syscall0(pid_t, gettid)
int main(int argc, char *argv[]) { printf("My tid is 0x%08x\n", gettid()); }
A quick update to this topic. As I alluded to in my original post, the real issue is that the _syscall0 macro is not defined. Actually, none of the _syscallx (where x goes from 0 to 6) macros are defined in /usr/include/linux/unistd.h as they are on a CentOS 4.4 system. I grep'ed in all of /usr/include and couldn't find any references to these macros. Have they been deprecated or is this an oversight? At least one man page (gettid) still references _syscall0...
Alfred
On Mon, Apr 02, 2007 at 11:58:28AM -0400, Alfred von Campe wrote:
I can't get the simple program below to compile on CentOS 5 beta. It compiles (and runs) just fine on CentOS 4.4, and I'm using gettid() as described in the man page. I wonder if this is a problem with RHEL 5 as well, but I don't have a system to test on. I also wonder if this is a gcc 4.1.1 issue or something missing in CentOS 5.
The issue is that the _syscall0 macro is not defined anywhere. If I copy and paste the following definition for _syscall0 from a CentOS 4.4 system into the test program, it works just fine:
#define _syscall0(type,name) \ type name(void) \ {\ return syscall(__NR_##name);\ }
Has anyone else run into this problem?
Alfred
I've got an APP at work that will need to be working on RH5 and possibly Centos 5 that uses gettid(), so I'm going to hang onto your posting just in case it is a problem in the real release. Haven't tried RH5 yet, but I will be (and Centos, too, once it comes out).
Thanks for the heads-up.
Could someone with access to a RHEL 5 system please post the output of the following command:
grep -RE "#define[[:space:]]+_syscall" /usr/include
I'd like to know if this problem affects RHEL 5 as well.
Thanks, Alfred
What packages do you need installed?
This is a base system, no dev packages...
/usr/include/asm/unistd.h:#define __NR_restart_syscall 0 /usr/include/asm/unistd.h:#define __NR_afs_syscall 137 /* Syscall for Andrew File System */
Let me know...
J.J.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Alfred von Campe Sent: Tuesday, April 03, 2007 3:38 PM To: CentOS mailing list Subject: Re: [CentOS] Problem with gettid() on CentOS 5/gcc 4.1.1
Could someone with access to a RHEL 5 system please post the output of the following command:
grep -RE "#define[[:space:]]+_syscall" /usr/include
I'd like to know if this problem affects RHEL 5 as well.
Thanks, Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
!DSPAM:500,4612bb3e156318882710782!
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM
What packages do you need installed?
On a CentOS 4.4 system I get the following:
# rpm -qf /usr/include/linux/unistd.h glibc-kernheaders-2.4-9.1.98.EL
and
# grep -RE "#define[[:space:]]+_syscall" /usr/include /usr/include/linux/unistd.h:#define _syscall0(type,name) \ /usr/include/linux/unistd.h:#define _syscall1(type,name,type1,arg1) \ /usr/include/linux/unistd.h:#define _syscall2 (type,name,type1,arg1,type2,arg2) \ /usr/include/linux/unistd.h:#define _syscall3 (type,name,type1,arg1,type2,arg2,type3,arg3) \ /usr/include/linux/unistd.h:#define _syscall4 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4) \ /usr/include/linux/unistd.h:#define _syscall5 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \ /usr/include/linux/unistd.h:#define _syscall6 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \
So the macros are being defined as expected, but not on my CentOS 5 beta system (then again, it is just a beta, but this file shouldn't change very often).
Alfred
[root@localhost /]# cat /proc/version Linux version 2.6.18-8.el5 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:15:21 EST 2007
[root@localhost /]# rpm -qf /usr/include/linux/unistd.h kernel-headers-2.6.18-8.el5
[root@localhost /]# cat /usr/include/linux/unistd.h #ifndef _LINUX_UNISTD_H_ #define _LINUX_UNISTD_H_
/* * Include machine specific syscallX macros */ #include <asm/unistd.h>
#endif /* _LINUX_UNISTD_H_ */
J.J.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Alfred von Campe Sent: Tuesday, April 03, 2007 8:22 PM To: CentOS mailing list Subject: Re: [CentOS] Problem with gettid() on CentOS 5/gcc 4.1.1
What packages do you need installed?
On a CentOS 4.4 system I get the following:
# rpm -qf /usr/include/linux/unistd.h glibc-kernheaders-2.4-9.1.98.EL
and
# grep -RE "#define[[:space:]]+_syscall" /usr/include /usr/include/linux/unistd.h:#define _syscall0(type,name) \ /usr/include/linux/unistd.h:#define _syscall1(type,name,type1,arg1) \ /usr/include/linux/unistd.h:#define _syscall2 (type,name,type1,arg1,type2,arg2) \ /usr/include/linux/unistd.h:#define _syscall3 (type,name,type1,arg1,type2,arg2,type3,arg3) \ /usr/include/linux/unistd.h:#define _syscall4 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4) \ /usr/include/linux/unistd.h:#define _syscall5 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \ /usr/include/linux/unistd.h:#define _syscall6 (type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \
So the macros are being defined as expected, but not on my CentOS 5 beta system (then again, it is just a beta, but this file shouldn't change very often).
Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
!DSPAM:500,4612fe0a163821804284693!
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/744 - Release Date: 4/3/2007 5:32 AM
On Apr 3, 2007, at 21:47, JJ Scott wrote:
[root@localhost /]# rpm -qf /usr/include/linux/unistd.h kernel-headers-2.6.18-8.el5
[root@localhost /]# cat /usr/include/linux/unistd.h #ifndef _LINUX_UNISTD_H_ #define _LINUX_UNISTD_H_
/*
- Include machine specific syscallX macros
*/ #include <asm/unistd.h>
#endif /* _LINUX_UNISTD_H_ */
Looks like the _syscall[0-6] macros no longer exist in RHEL 5/CentOS 5. So, what does that mean if you want to use something like gettid () that requires it (or something equivalent)? The following man pages reference _syscall[0-6] on a CentOS 4.4 system (I don't have access to a CentOS 5 beta system from home, but I'll be checking it tomorrow):
/usr/share/man/man2/clone.2.gz /usr/share/man/man2/getdents.2.gz /usr/share/man/man2/gettid.2.gz /usr/share/man/man2/intro.2.gz /usr/share/man/man2/llseek.2.gz /usr/share/man/man2/mmap2.2.gz /usr/share/man/man2/modify_ldt.2.gz /usr/share/man/man2/pivot_root.2.gz /usr/share/man/man2/readdir.2.gz /usr/share/man/man2/setup.2.gz /usr/share/man/man2/sysctl.2.gz /usr/share/man/man2/syslog.2.gz /usr/share/man/man2/tkill.2.gz
A quick search on the Red Hat Bugzilla system did not find anything on this topic. It sure does smell like an upstream bug/issue/ something to me...
Alfred
On Tue, Apr 03, 2007 at 11:34:31PM -0400, Alfred von Campe wrote:
Looks like the _syscall[0-6] macros no longer exist in RHEL 5/CentOS 5. So, what does that mean if you want to use something like gettid () that requires it (or something equivalent)?
_syscall* is deprecated, syscall(2) is the real thing now.
The following man pages reference _syscall[0-6] on a CentOS 4.4 system (I don't have access to a CentOS 5 beta system from home, but I'll be checking it tomorrow):
My man gettid: _syscall0(pid_t, gettid) /* Using syscall(2) may be preferable; see intro(2) */
So they do reference syscall(2).
On Apr 4, 2007, at 3:49, Luciano Miguel Ferreira Rocha wrote:
_syscall* is deprecated, syscall(2) is the real thing now.
Yes, I saw that. But I don't think this is documented well enough.
My man gettid: _syscall0(pid_t, gettid) /* Using syscall(2) may be preferable; see intro(2) */
So they do reference syscall(2).
The intro(2) man page talks mostly about the _syscall macros. Near the end of the man page, in the NOTES section, we find the following paragraphs:
The preferred way to invoke system calls that glibc does not know about yet is via syscall(2). However, this mechanism can only be used if using a libc (such as glibc) that supports syscall(2), and if the <sys/syscall.h> header file contains the required SYS_foo definition. Otherwise, the use of a _syscall macro is required.
Some architectures, notably ia64, do not provide the _syscall macros. On these architectures, syscall(2) must be used.
So it boils down to this: On CentOS 4, to use gettid() you do this:
_syscall0(pid_t, gettid) mytid = gettid()
and on CentOS 5, you have to do this:
pid_t gettid(void) { return syscall(__NR_gettid); } mytid = gettid();
or this:
mytid = (pid_t)syscall(__NR_gettid);
My only gripe is that the gettid man page should not refer to _sycall0 at all since it is not defined and just show the syscall() syntax directly. I realize this is not a CentOS issue, but rather an upstream issue. I still think they dropped the ball on this one, and if I had a support contract I would file a bug.
Alfred
On Wed, Apr 04, 2007 at 10:10:50AM -0400, Alfred von Campe enlightened us:
My only gripe is that the gettid man page should not refer to _sycall0 at all since it is not defined and just show the syscall() syntax directly. I realize this is not a CentOS issue, but rather an upstream issue. I still think they dropped the ball on this one, and if I had a support contract I would file a bug.
You don't need a support contract to file a bugzilla. I would encourage you to do so and put in all the detail that you (and others?) have described on this list.
Matt
On Apr 4, 2007, at 10:21, Matt Hyclak wrote:
You don't need a support contract to file a bugzilla. I would encourage you to do so and put in all the detail that you (and others?) have described on this list.
Done! See https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=235206 for details.
Alfred
On Tue, 3 Apr 2007, Alfred von Campe wrote:
Could someone with access to a RHEL 5 system please post the output of the following command:
grep -RE "#define[[:space:]]+_syscall" /usr/include
I'd like to know if this problem affects RHEL 5 as well.
I can confirm same ugliness (ie. empty output) on ubuntu - it just seems to be the way this is done now...
I've taken to defining it on my own in my own project file. I expect the reasoning for dropping this was to enable the use of sysenter & friends.
- Maciej
-
Alfred von Campe -
fredex -
JJ Scott -
Luciano Miguel Ferreira Rocha -
Maciej Zenczykowski -
Matt Hyclak