From: "Dmitry V. Levin" <ldv@altlinux.org>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] S390: Sync ptrace.h with kernel. [BZ #21539]
Date: Tue, 18 Jul 2017 14:16:00 -0000 [thread overview]
Message-ID: <20170718141535.GB23830@altlinux.org> (raw)
In-Reply-To: <2e9fcbdc-4060-5e1d-8866-82aaca9316b1@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]
On Tue, Jul 18, 2017 at 03:41:41PM +0200, Stefan Liebler wrote:
> On 07/18/2017 12:20 PM, Dmitry V. Levin wrote:
> > On Mon, Jun 19, 2017 at 03:10:57PM +0200, Stefan Liebler wrote:
[...]
> > Mark Wielaard has spotted [1] a regression that I missed during review.
> > After this change, this test case fails to compile with the following
> > diagnostics:
> >
> > $ gcc -c -xc -o/dev/null - <<'EOF'
> > #include <asm/ptrace.h>
> > #include <sys/ptrace.h>
> > EOF
> Is this order required?
No, the reversed order also works.
> I've tried it on x86_64 RHEL 7.3:
> In file included from /usr/include/asm/ptrace.h:5:0,
> from <stdin>:1:
> /usr/include/sys/ptrace.h:74:4: error: expected identifier before
> numeric constant
> PTRACE_GETREGS = 12,
> ^
Interesting. So it means that it didn't work with some old linux headers.
However, it used to work with recent linux headers and glibc-2.25.
> > In file included from <stdin>:1:0:
> > /usr/include/sys/ptrace.h:93:3: error: expected identifier before numeric constant
> > PTRACE_SINGLEBLOCK = 12,
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:158:0: warning: "PTRACE_PEEKUSR_AREA" redefined
> > #define PTRACE_PEEKUSR_AREA PTRACE_PEEKUSR_AREA
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:392:0: note: this is the location of the previous definition
> > #define PTRACE_PEEKUSR_AREA 0x5000
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:161:0: warning: "PTRACE_POKEUSR_AREA" redefined
> > #define PTRACE_POKEUSR_AREA PTRACE_POKEUSR_AREA
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:393:0: note: this is the location of the previous definition
> > #define PTRACE_POKEUSR_AREA 0x5001
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:164:0: warning: "PTRACE_GET_LAST_BREAK" redefined
> > #define PTRACE_GET_LAST_BREAK PTRACE_GET_LAST_BREAK
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:398:0: note: this is the location of the previous definition
> > #define PTRACE_GET_LAST_BREAK 0x5006
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:167:0: warning: "PTRACE_ENABLE_TE" redefined
> > #define PTRACE_ENABLE_TE PTRACE_ENABLE_TE
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:401:0: note: this is the location of the previous definition
> > #define PTRACE_ENABLE_TE 0x5009
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:170:0: warning: "PTRACE_DISABLE_TE" redefined
> > #define PTRACE_DISABLE_TE PTRACE_DISABLE_TE
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:402:0: note: this is the location of the previous definition
> > #define PTRACE_DISABLE_TE 0x5010
> > ^
> > In file included from <stdin>:2:0:
> > /usr/include/sys/ptrace.h:173:0: warning: "PTRACE_TE_ABORT_RAND" redefined
> > #define PTRACE_TE_ABORT_RAND PTRACE_TE_ABORT_RAND
> > ^
> > In file included from <stdin>:1:0:
> > /usr/include/asm/ptrace.h:403:0: note: this is the location of the previous definition
> > #define PTRACE_TE_ABORT_RAND 0x5011
> > ^
> >
> > The following change fixes this and similar compilation issues that arise
> > when sys/ptrace.h is included after linux/ptrace.h:
> >
> > --- a/sysdeps/unix/sysv/linux/s390/sys/ptrace.h
> > +++ b/sysdeps/unix/sysv/linux/s390/sys/ptrace.h
> > @@ -24,24 +24,61 @@
> > #include <bits/types.h>
> >
> > __BEGIN_DECLS
> > -#ifdef _LINUX_PTRACE_H
> > +#if defined _LINUX_PTRACE_H || defined _S390_PTRACE_H
> Shall we also add "|| defined _UAPI_LINUX_PTRACE_H" here?
Isn't _UAPI prefix automatically stripped during linux headers export
procedure?
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-07-18 14:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 10:17 Stefan Liebler
2017-06-06 10:44 ` Andreas Schwab
2017-06-06 10:58 ` Dmitry V. Levin
2017-06-06 11:56 ` Stefan Liebler
2017-06-08 12:02 ` Stefan Liebler
2017-06-13 20:05 ` Dmitry V. Levin
2017-06-19 13:11 ` Stefan Liebler
2017-06-19 13:26 ` Dmitry V. Levin
2017-06-19 14:34 ` Stefan Liebler
2017-06-30 10:09 ` Florian Weimer
2017-07-04 8:22 ` Stefan Liebler
2017-07-04 9:41 ` Florian Weimer
2017-07-04 15:37 ` Stefan Liebler
2017-07-07 10:22 ` Stefan Liebler
2017-07-07 10:45 ` Florian Weimer
2017-07-07 13:54 ` Stefan Liebler
2017-07-11 8:39 ` Stefan Liebler
2017-07-18 10:20 ` Dmitry V. Levin
2017-07-18 13:31 ` Carlos O'Donell
2017-07-18 13:39 ` Dmitry V. Levin
2017-07-18 14:11 ` Carlos O'Donell
2017-07-18 14:28 ` Mark Wielaard
2017-07-18 14:40 ` Mark Wielaard
2017-07-20 7:38 ` Stefan Liebler
2017-07-20 8:07 ` Carlos O'Donell
2017-07-20 8:32 ` Stefan Liebler
2017-07-24 3:51 ` Dmitry V. Levin
2017-07-24 7:18 ` Stefan Liebler
2017-07-18 13:41 ` Stefan Liebler
2017-07-18 14:12 ` Carlos O'Donell
2017-07-18 14:16 ` Dmitry V. Levin [this message]
2017-07-19 8:40 ` Stefan Liebler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170718141535.GB23830@altlinux.org \
--to=ldv@altlinux.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).