Skip to contentSkip to conversation

jack2: Try better fix for NGREG problem

PATCH New Alexey Brodkin 2 participants 6 messages Nov 21, 2016 – Dec 19, 2016

lore
Share & tools
lore

Alexey Brodkin

author
#0 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

After quite some time trying this and that we seem to have no better solution than proposed by Thomas back in the day [1].

The solution in question is to check [during jack2 configuration] if NGREG is exposed via ucontext.h and then use its value in source code later on. This replaces long and still growing list of architectures for which we explicitly escape usage of NGREG.

Just for reference [2] is my attempt to fix in in the other supposedly better way but with no luck because of the mess in kernel's UAPI headers.

[1] http://lists.busybox.net/pipermail/buildroot/2016-May/161785.html
[2] http://lists.busybox.net/pipermail/buildroot/2016-June/162461.html

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

Signed-off-by Alexey Brodkin <[email protected]>
Cc Bernd Kuhls <[email protected]>
Cc Thomas Petazzoni <[email protected]>
Cc Arnout Vandecappelle <[email protected]>
Cc Waldemar Brodkorb <[email protected]>
---
 package/jack2/0001-Add-support-for-nios2.patch     | 34 --------------
 .../jack2/0004-Add-check-for-the-NGREG-macro.patch | 52 ++++++++++++++++++++++
 2 files changed, 52 insertions(+), 34 deletions(-)
 delete mode 100644 package/jack2/0001-Add-support-for-nios2.patch
 create mode 100644 package/jack2/0004-Add-check-for-the-NGREG-macro.patch
package/jack2/0001-Add-support-for-nios2.patch deleted +0 -34
deleted file mode 100644
index f6d60af..0000000
@@ -1,34 +0,0 @@
-From 3651f95d0433c84d2b67e30e68dd6140585535b0 Mon Sep 17 00:00:00 2001
-From: Bernd Kuhls <[email protected]>
-Date: Tue, 19 Apr 2016 19:32:35 +0200
-Subject: [PATCH 1/1] Add support for nios2
-
-When compiling jack on nios2, compilation fails because NGREGS is not
-defined. Since this is only for debug output on segmentation faults, stub
-the debug print out like it's been done for other platforms before.
-
-Inspired by
-https://github.com/jackaudio/jack2/commit/d11bb095291d8880508c87adfe625bf2bcab1456
-
-Signed-off-by: Bernd Kuhls <[email protected]>
-[Patch sent upstream: https://github.com/jackaudio/jack2/pull/199]
----
- dbus/sigsegv.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/dbus/sigsegv.c b/dbus/sigsegv.c
-index 64c3986..ee12f91 100644
---- a/dbus/sigsegv.c
-+++ b/dbus/sigsegv.c
-@@ -104,7 +104,7 @@ static void signal_segv(int signum, siginfo_t* info, void*ptr) {
-     jack_error("info.si_errno = %d", info->si_errno);
-     jack_error("info.si_code  = %d (%s)", info->si_code, si_code_str);
-     jack_error("info.si_addr  = %p", info->si_addr);
--#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) && !defined(__aarch64__)
-+#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) && !defined(__aarch64__) && !defined(nios2)
-     for(i = 0; i < NGREG; i++)
-         jack_error("reg[%02d]       = 0x" REGFORMAT, i, 
- #if defined(__powerpc64__)
--- 
-2.8.0.rc3
-
package/jack2/0004-Add-check-for-the-NGREG-macro.patch new file +52 -0

52 lines not on this page · raw message

Signature · 1 line
2.6.3
#1 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

Hello,

Quoted 12 lines · Alexey Brodkin

After quite some time trying this and that we seem to have no better solution than proposed by Thomas back in the day [1].

The solution in question is to check [during jack2 configuration] if NGREG is exposed via ucontext.h and then use its value in source code later on. This replaces long and still growing list of architectures for which we explicitly escape usage of NGREG.

Just for reference [2] is my attempt to fix in in the other supposedly better way but with no luck because of the mess in kernel's UAPI headers.

Quoted 5 lines

[1] http://lists.busybox.net/pipermail/buildroot/2016-May/161785.html
[2] http://lists.busybox.net/pipermail/buildroot/2016-June/162461.html

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

Unfortunately, I experimented with something like this some time ago, and IIRC, it didn't work all architectures, because NGREG is not always defined in <ucontext.h>, but can be defined in other header files (if I recall). In the end, I think I ended up with something like the below, but I don't remember if I tested it in all cases:

(As you can see, it dates back from May 2016...)

author
#2 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

Hi Thomas,

Quoted 41 lines · Thomas Petazzoni

Hello,

Quoted 13 lines · Alexey Brodkin

After quite some time trying this and that we seem to have no better solution than proposed by Thomas back in the day [1].

The solution in question is to check [during jack2 configuration] if NGREG is exposed via ucontext.h and then use its value in source code later on. This replaces long and still growing list of architectures for which we explicitly escape usage of NGREG.

Just for reference [2] is my attempt to fix in in the other supposedly better way but with no luck because of the mess in kernel's UAPI headers.

Quoted 5 lines

[1] http://lists.busybox.net/pipermail/buildroot/2016-May/161785.html
[2] http://lists.busybox.net/pipermail/buildroot/2016-June/162461.html

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

Unfortunately, I experimented with something like this some time ago, and IIRC, it didn't work all architectures, because NGREG is not always defined in <ucontext.h>, but can be defined in other header files (if I recall). In the end, I think I ended up with something like the below, but I don't remember if I tested it in all cases:

(As you can see, it dates back from May 2016...)

From 15685fd4409486e7059bb480193d1086c5634910 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni <[email protected]>
Date: Mon, 23 May 2016 22:28:12 +0200
Subject: [PATCH] Improve check for ucontext

The ucontext functionality is not available on all CPUs with all C libraries. Instead of making just assumptions based on the CPU architecture, this commit adds the necessary checks in wscript to verify the availability of the ucontext functionality, before using it in dbus/sigsegv.c.

Quoted 8 lines

This avoids the long list of architecture exclusions, and make it more robust when building jack2 for new CPU architectures.

Signed-off-by Thomas Petazzoni <[email protected]>

---
?dbus/sigsegv.c | 12 ++++++------ ?wscript????????| 11 ++++++++++-
?2 files changed, 16 insertions(+), 7 deletions(-)

That now looks really scary.
Maybe we follow much cleaner path and will remove that damned check where NGREG is used all together? Anyways it was used let's say "not always" so that might be not that bad solution.

What do you think?

Not sure if that corner case really requires more time from us.

-Alexey

#3 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

In reply to Alexey Brodkin

Hello,

Quoted 12 lines · Alexey Brodkin

After quite some time trying this and that we seem to have no better solution than proposed by Thomas back in the day [1].

The solution in question is to check [during jack2 configuration] if NGREG is exposed via ucontext.h and then use its value in source code later on. This replaces long and still growing list of architectures for which we explicitly escape usage of NGREG.

Just for reference [2] is my attempt to fix in in the other supposedly better way but with no luck because of the mess in kernel's UAPI headers.

Quoted 5 lines

[1] http://lists.busybox.net/pipermail/buildroot/2016-May/161785.html
[2] http://lists.busybox.net/pipermail/buildroot/2016-June/162461.html

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

I have submitted an improved version of this:

https://patchwork.ozlabs.org/patch/706714/

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#4 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

Hi Thomas,

Quoted 23 lines · Thomas Petazzoni

Hello,

Quoted 20 lines · Alexey Brodkin

After quite some time trying this and that we seem to have no better solution than proposed by Thomas back in the day [1].

The solution in question is to check [during jack2 configuration] if NGREG is exposed via ucontext.h and then use its value in source code later on. This replaces long and still growing list of architectures for which we explicitly escape usage of NGREG.

Just for reference [2] is my attempt to fix in in the other supposedly better way but with no luck because of the mess in kernel's UAPI headers.

[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.busybox.net_pipermail_buildroot_2016-2DMay_161785.html
&d=DgICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=lO- pWm8TsFCI8LpRpFt8VMDAaoxteVHDKeXx2lKUc6M&s=nQ80Ho3tQdAjjk76kuGcuhh_PBE9EAEFNOpYeQIryrk&e=?
[2] https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.busybox.net_pipermail_buildroot_2016-2DJune_162461.htm
l&d=DgICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=lO- pWm8TsFCI8LpRpFt8VMDAaoxteVHDKeXx2lKUc6M&s=37fBEUzi8Cri1lFd5OsOcCvWM_MYPDctH0kR9fYlTRM&e=?

Quoted 4 lines
Quoted 2 lines

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

I have submitted an improved version of this:

Thanks for doing that!
Let's see if Jack2 appears in Autobuilder failures again now.

-Alexey

#5 lore raw

PATCH 1/1 jack2: Try better fix for NGREG problem

Hello,

Quoted 7 lines · Alexey Brodkin
Quoted 4 lines
Quoted 2 lines

Still not sure if that works for every other architectures, so testing and Acks from all interested parties are much appreciated.

I have submitted an improved version of this:

Thanks for doing that!
Let's see if Jack2 appears in Autobuilder failures again now.

I haven't applied the patch yet, so it's not going to fix autobuilder issues for the moment.

I was waiting for some review before applying the patch.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com