All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: rpm@xenomai.org
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig	refences pthread_kill
Date: Tue, 15 Aug 2006 14:20:47 +0200	[thread overview]
Message-ID: <44E1BC1F.7030208@domain.hid> (raw)
In-Reply-To: <1155642921.4327.7.camel@domain.hid>


[-- Attachment #1.1: Type: text/plain, Size: 2804 bytes --]

Philippe Gerum wrote:
> On Tue, 2006-08-15 at 10:15 +0200, Jan Kiszka wrote:
>> Niklaus Giger wrote:
>>> Hi
>>>
>>> All my PPC based compilation fail with something like
>>>
>>> ccache gcc -rdynamic -o .libs/rtcanconfig 
>>> rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
>>> /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
>>> undefined reference to `pthread_kill'
>>> http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
>>> Is this only a PPC problem? It appears first with build 226, which referred to 
>>> revisions 1433 and 1434. Details see 
>>> http://ngiger.dyndns.org/buildbot/ppc/builds/226
>>>
>>> Jan, could you please have a look at the error, as it seems to me that you 
>>> reduced the lib dependencies a little bit too much?
>> Well, neither rtcanconfig nor librtdm have explicit dependencies on
>> libpthread. Unfortunately, the generic skin init code now drags in
>> pthread_kill when the linker fails to remove xeno_handle_mlock_alert for
>> librtdm. That doesn't happen with my gcc-4.1, likely older compilers are
>> less smart.
>>
>> Anyone any ideas how to solve it WITHOUT adding -lpthread to librtdm?
> 
> Could you develop a bit more, i.e. what's the issue with adding this
> dependency?

It's simply unneeded. This is only a single tiny tool, but we may see
more of them in the future, so I would like to clean this up now.

> 
>>  I
>> would say either move that functions to a separate module
> 
> The reason to have this code in nucleus/bind.h is that we don't have any
> dependency on common libs aside of the ones providing the skin syscalls,
> and we try to avoid code duplication by not implementing this stuff into
> each and every init.c files.
> 
>>  or include it
>> via a separate header that all skins include except rtdm.
>>
> 
> I'm still reluctant to make RTDM an exception to the common rule,
> especially to fix a compiler issue.

Actually, the issue is slightly broader, though with varying
significance. The current approach drags xeno_handle_mlock_alert and
xeno_sigxcpu_no_mlock multiple times into the skin lib. Even with
gcc-4.1 that increases libnative by a few data bytes, under 3.3 by ~300
byte of dead code (overall increase of /lib with 3.3: 32 Kbyte).

The attached patch solves both the linking issue and avoids multiple
static includes of code and variables that are only required once. I
think it's cleaner this way, following the idea of asm/bits/ (BTW,
should it become a asm-generic/bits header?).

Jan

[-- Attachment #1.2: separate_mlock_alert.patch --]
[-- Type: text/plain, Size: 4045 bytes --]

Index: include/nucleus/mlock_alert.h
===================================================================
--- include/nucleus/mlock_alert.h	(revision 0)
+++ include/nucleus/mlock_alert.h	(revision 0)
@@ -0,0 +1,37 @@
+#ifndef _XENO_NUCLEUS_MLOCK_ALERT_H
+#define _XENO_NUCLEUS_MLOCK_ALERT_H
+
+#ifndef __XENO_SIM__
+#include <stdio.h>
+#include <stdlib.h>
+#include <signal.h>
+#include <pthread.h>
+
+__attribute__ ((weak))
+int xeno_sigxcpu_no_mlock = 1;
+
+__attribute__ ((visibility ("internal")))
+void xeno_handle_mlock_alert(int sig)
+{
+	struct sigaction sa;
+
+	if (xeno_sigxcpu_no_mlock) {
+		fprintf(stderr, "Xenomai: process memory not locked "
+			"(missing mlockall?)\n");
+		fflush(stderr);
+		exit(4);
+	}
+
+	/* XNTRAPSW was set for the thread but no user-defined handler
+	   has been set to override our internal handler, so let's
+	   invoke the default signal action. */
+
+	sa.sa_handler = SIG_DFL;
+	sigemptyset(&sa.sa_mask);
+	sa.sa_flags = 0;
+	sigaction(SIGXCPU, &sa, NULL);
+	pthread_kill(pthread_self(), SIGXCPU);
+}
+#endif /* __XENO_SIM__ */
+
+#endif /* _XENO_NUCLEUS_MLOCK_ALERT_H */
Index: include/nucleus/bind.h
===================================================================
--- include/nucleus/bind.h	(revision 1440)
+++ include/nucleus/bind.h	(working copy)
@@ -6,33 +6,9 @@
 #include <string.h>
 #include <errno.h>
 #include <signal.h>
-#include <pthread.h>
 #include <asm/xenomai/syscall.h>
 
-__attribute__ ((weak))
-int xeno_sigxcpu_no_mlock = 1;
-
-static void xeno_handle_mlock_alert(int sig)
-{
-	struct sigaction sa;
-
-	if (xeno_sigxcpu_no_mlock) {
-		fprintf(stderr,
-			"Xenomai: process memory not locked (missing mlockall?)\n");
-		fflush(stderr);
-		exit(4);
-	}
-
-	/* XNTRAPSW was set for the thread but no user-defined handler
-	   has been set to override our internal handler, so let's
-	   invoke the default signal action. */
-
-	sa.sa_handler = SIG_DFL;
-	sigemptyset(&sa.sa_mask);
-	sa.sa_flags = 0;
-	sigaction(SIGXCPU, &sa, NULL);
-	pthread_kill(pthread_self(), SIGXCPU);
-}
+void xeno_handle_mlock_alert(int sig);
 
 static inline int
 xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
Index: src/skins/rtai/init.c
===================================================================
--- src/skins/rtai/init.c	(revision 1440)
+++ src/skins/rtai/init.c	(working copy)
@@ -20,6 +20,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <rtai/syscall.h>
+#include <nucleus/mlock_alert.h>
 
 int __rtai_muxid = -1;
 
Index: src/skins/posix/init.c
===================================================================
--- src/skins/posix/init.c	(revision 1440)
+++ src/skins/posix/init.c	(working copy)
@@ -26,6 +26,7 @@
 #include <posix/posix.h>
 #include <posix/syscall.h>
 #include <rtdm/syscall.h>
+#include <nucleus/mlock_alert.h>
 
 int __pse51_muxid = -1;
 int __rtdm_muxid = -1;
Index: src/skins/vxworks/init.c
===================================================================
--- src/skins/vxworks/init.c	(revision 1440)
+++ src/skins/vxworks/init.c	(working copy)
@@ -23,6 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vxworks/vxworks.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __vxworks_tskey;
 
Index: src/skins/vrtx/init.c
===================================================================
--- src/skins/vrtx/init.c	(revision 1440)
+++ src/skins/vrtx/init.c	(working copy)
@@ -23,6 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vrtx/vrtx.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __vrtx_tskey;
 
Index: src/skins/native/init.c
===================================================================
--- src/skins/native/init.c	(revision 1440)
+++ src/skins/native/init.c	(working copy)
@@ -24,6 +24,7 @@
 #include <pthread.h>
 #include <native/syscall.h>
 #include <native/task.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __native_tskey;
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

  reply	other threads:[~2006-08-15 12:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-15  7:49 [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill Niklaus Giger
2006-08-15  8:15 ` Jan Kiszka
2006-08-15 11:55   ` Philippe Gerum
2006-08-15 12:20     ` Jan Kiszka [this message]
2006-08-15 13:44       ` Philippe Gerum
2006-08-15 18:14 ` Jan Kiszka
2006-08-15 18:56   ` Niklaus Giger
2006-08-15 19:46     ` Jan Kiszka
2006-08-15 21:29     ` Philippe Gerum
2006-08-16 13:23     ` Gilles Chanteperdrix
2006-08-16 17:37       ` Niklaus Giger

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=44E1BC1F.7030208@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.