glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa, but that seems unavoidable in the growth of a new port, and the workaround of checking for header defines and defining one to the other seems unpleasant as well. Therefore, bite the bullet, and let packaging systems alter their build requires accordingly.
--- a/backends/aarch64_initreg.c +++ b/backends/aarch64_initreg.c @@ -51,7 +51,7 @@ aarch64_set_initial_registers_tid (pid_t tid __attribute__ ((unused)), #else /* __aarch64__ */
/* General registers. */ - struct user_pt_regs gregs; + struct user_regs_struct gregs; struct iovec iovec; iovec.iov_base = &gregs; iovec.iov_len = sizeof (gregs); @@ -69,7 +69,7 @@ aarch64_set_initial_registers_tid (pid_t tid __attribute__ ((unused)), /* ELR cannot be found. */
/* FP registers (only 64bits are used). */ - struct user_fpsimd_state fregs; + struct user_fpsimd_struct fregs; iovec.iov_base = &fregs; iovec.iov_len = sizeof (fregs); if (ptrace (PTRACE_GETREGSET, tid, NT_FPREGSET, &iovec) != 0) diff --git a/backends/arm_initreg.c b/backends/arm_initreg.c index 5837383..1edf62b 100644 --- a/backends/arm_initreg.c +++ b/backends/arm_initreg.c @@ -67,7 +67,7 @@ arm_set_initial_registers_tid (pid_t tid __attribute__ ((unused)), #elif defined __aarch64__ /* Compat mode: arm compatible code running on aarch64 */ int i; - struct user_pt_regs gregs; + struct user_regs_struct gregs; struct iovec iovec; iovec.iov_base = &gregs; iovec.iov_len = sizeof (gregs);
On Mon, 2014-06-09 at 21:06 +0200, Kyle McMartin wrote:
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa, but that seems unavoidable in the growth of a new port, and the workaround of checking for header defines and defining one to the other seems unpleasant as well. Therefore, bite the bullet, and let packaging systems alter their build requires accordingly.
That is indeed annoying, but using the glibc defined structs seems to be the right thing to do. Do you know which glibc version introduced them?
BTW. For this trivial patch it doesn't really matter, but in general we like to have a Signed-off-by line for all patches to indicate contributors know about and agree with our CONTRIBUTING guidelines. Would you mind adding one? https://git.fedorahosted.org/cgit/elfutils.git/tree/CONTRIBUTING
Thanks,
Mark
On Tue, Jun 10, 2014 at 11:51:48AM +0200, Mark Wielaard wrote:
On Mon, 2014-06-09 at 21:06 +0200, Kyle McMartin wrote:
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa, but that seems unavoidable in the growth of a new port, and the workaround of checking for header defines and defining one to the other seems unpleasant as well. Therefore, bite the bullet, and let packaging systems alter their build requires accordingly.
That is indeed annoying, but using the glibc defined structs seems to be the right thing to do. Do you know which glibc version introduced them?
Hrm, looks like it's rawhide churn which has caused this... I guess it'll be in glibc 2.20, but isn't in a released version. I can sit on this and resend this patch when it is, if you'd like?
BTW. For this trivial patch it doesn't really matter, but in general we like to have a Signed-off-by line for all patches to indicate contributors know about and agree with our CONTRIBUTING guidelines. Would you mind adding one? https://git.fedorahosted.org/cgit/elfutils.git/tree/CONTRIBUTING
Sure, I'll add this to the v2 for the next glibc release? Otherwise adding Signed-off-by: Kyle McMartin kyle@redhat.com is fine by me.
regards, Kyle
Thanks,
Mark
On Tue, 2014-06-10 at 09:37 -0400, Kyle McMartin wrote:
On Tue, Jun 10, 2014 at 11:51:48AM +0200, Mark Wielaard wrote:
On Mon, 2014-06-09 at 21:06 +0200, Kyle McMartin wrote:
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa, but that seems unavoidable in the growth of a new port, and the workaround of checking for header defines and defining one to the other seems unpleasant as well. Therefore, bite the bullet, and let packaging systems alter their build requires accordingly.
That is indeed annoying, but using the glibc defined structs seems to be the right thing to do. Do you know which glibc version introduced them?
Hrm, looks like it's rawhide churn which has caused this... I guess it'll be in glibc 2.20, but isn't in a released version. I can sit on this and resend this patch when it is, if you'd like?
I think that would be better. I don't think we'll do the next elfutils release before glibc 2.20 is released. But if we do, it would be somewhat inconvenient if we relied on an unreleased glibc version.
I'll probably remember because I see the patch is in fedora rawhide now and when releasing I make sure all fedora distro patches have been properly upstreamed. But if you could remind me when glibc 2.20 is released that would be appreciated.
Thanks,
Mark
On Thu, 2014-06-12 at 14:37 +0200, Mark Wielaard wrote:
On Tue, 2014-06-10 at 09:37 -0400, Kyle McMartin wrote:
On Tue, Jun 10, 2014 at 11:51:48AM +0200, Mark Wielaard wrote:
On Mon, 2014-06-09 at 21:06 +0200, Kyle McMartin wrote:
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa, but that seems unavoidable in the growth of a new port, and the workaround of checking for header defines and defining one to the other seems unpleasant as well. Therefore, bite the bullet, and let packaging systems alter their build requires accordingly.
That is indeed annoying, but using the glibc defined structs seems to be the right thing to do. Do you know which glibc version introduced them?
Hrm, looks like it's rawhide churn which has caused this... I guess it'll be in glibc 2.20, but isn't in a released version. I can sit on this and resend this patch when it is, if you'd like?
I think that would be better. I don't think we'll do the next elfutils release before glibc 2.20 is released. But if we do, it would be somewhat inconvenient if we relied on an unreleased glibc version.
Meanwhile it became a bit inconvenient because some other distros also switched to a glibc 2.20-prerelease setup, but stable aarch64 distros are still on older glibc. I think we just have to add the configure check. Which I added to your patch. I tested it against old and new glibc setups on aarch64. What do you think? Does that look OK?
Thanks,
Mark
From 5df2dc63e96808afb1602d4338e30dbca560a656 Mon Sep 17 00:00:00 2001 From: Kyle McMartin kyle@redhat.com Date: Mon, 9 Jun 2014 21:06:26 +0200 Subject: [PATCH] aarch64: use <sys/user.h> defined register structures
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa. So include a new configure check for the new struct names and use the old ones if they are not avilable.
Signed-off-by: Kyle McMartin kyle@redhat.com Signed-off-by: Mark Wielaard mjw@redhat.com
It seems to do the right thing with old/new aarch64 glibc so I pushed this to master now.
Cheers,
Mark
On Fri, Aug 01, 2014 at 12:42:37PM +0200, Mark Wielaard wrote:
From 5df2dc63e96808afb1602d4338e30dbca560a656 Mon Sep 17 00:00:00 2001 From: Kyle McMartin kyle@redhat.com Date: Mon, 9 Jun 2014 21:06:26 +0200 Subject: [PATCH] aarch64: use <sys/user.h> defined register structures
glibc now supplies these (compatible) structs instead of including the kernel's <asm/ptrace.h> header, so let's use them. Annoyingly this will cause new elfutils to FTBFS on old glibc, and vice versa. So include a new configure check for the new struct names and use the old ones if they are not avilable.
Signed-off-by: Kyle McMartin kyle@redhat.com Signed-off-by: Mark Wielaard mjw@redhat.com
It seems to do the right thing with old/new aarch64 glibc so I pushed this to master now.
awesome, thanks very much mark, sorry for the radio silence.
--kyle
Cheers,
Mark
elfutils-devel@lists.fedorahosted.org