Re: Useless dovetail hacks
On 11.09.20 18:32, Philippe Gerum wrote: > > Jan Kiszka via Xenomai writes: > >> Hi all, >> >> to permit sharing the work of porting Xenomai over dovetail, I finally >> pushed my baseline hacks to [1]. You can "use" that on [2] (use >> fa1e9ba5e822, 0d68e5607286 leaks evl bits and is broken) > > Fixed on top of [2] now, thanks. > Thanks, confirmed! >> just like you >> would for an I-pipe kernel (prepare-kernel.sh). The thing builds for me, >> it even starts and gives a prompt, but that's because of >> >> [1.186025] [Xenomai] init failed, code -19 >> >> All the timing stuff is not mapped yet. Like a lot of other things. ETIME... >> > > This rough enumeration of what would change in Cobalt as a result of > rebasing on Dovetail still applies: > > https://xenomai.org/pipermail/xenomai/2020-February/042488.html > > To summarize this, a significant issue would involve switching the > xntimer abstraction to nanosecs, dropping all references to the internal > time unit which may be used by the clock and timer devices (e.g. TSC on > x86, free running counters from assorted ARM/aarch64 timers). I'm thinking of running with timers/clocks that have a 1:1 translation in first step. Obviously, that is not optimal. > > Overall, switching to Dovetail entails disabling a significant amount of > low-level code from Cobalt, which implements features the former already > handles (like core context switch support, fpu sharing between execution > stages, shared interrupt support [in xnintr] and reading the POSIX > clocks from the real-time context via the generic vDSO). > >> Please raise your hand when you'd like to join this endeavor, then we >> can discuss a split-up of tasks. Next steps would be: >> >> - make it initialize dovetail properly and activate Xenomai >> - hack on it until Xenomai tasks work properly >> - look at the result an decide how to integrate with I-pipe or whether >> to make this Xenomai 3.2 without any I-pipe support > > Assuming you meant that an option might be to enable Xenomai 3.1 to run > over Dovetail, I would say that a Dovetail-based Cobalt core implies > Xenomai 3.2+ instead, because 3.1.x is deemed stable, therefore the ABI > changes involved in such a transition should not make their way into the > stable tree. There is also the issue of ppc32 and x86_32, which > Dovetail does not support. x86_32 is long gone, no one needs this anymore. ppc32 is different, but we would not hold breath if one arch is not able to follow in time. I wouldn't see an issue with leaving a combination initially unsupported. Anyway, the criteria for 3.2 vs. 3.1 enhancement is whether we can keep the kernel-user ABI stable. I have no concrete feeling for that yet. Primarily, we are working on the kernel internals. But prio is on being able to move forward, and if that is much simpler via a new major release, than we will do that. > > Although having both ABIs live side-by-side in a way that would maintain > backward compat with I-pipe kernels might be done, the result would not > be pretty implementation-wise: redundancies and ugly wrappings to be > expected in libcobalt, and two set of build settings for the latter > depending on which ABI is targeted to avoid indirect calls all over the > place. Which would also require having separate sets of user-space > libraries, specifically built for one IRQ pipeline core or the > other, adding to the confusion. Can you give some example where ipipe concepts "leak" into userspace? > > On a more general note, isn't the issue about which should be the final > kernel release the project would pledge to support with Xenomai 3.1.x? > > As of today, Xenomai 3.1 is (almost) running kernel 5.4 LTS over the > I-pipe, at least on x86. If things go as usual upstream, the next LTS > kernel is going to be post-5.7, which means the effort in porting the > I-pipe to the next LTS release may be quite significant, with many > conflicts to expect between the upstream changes and the pipeline code > starting from kernel 5.8, particularly for x86. For this reason, keeping > the Cobalt core compatible with the I-pipe beyond kernel 5.4, adding > support for Dovetail the right way in the meantime seems a hard nut to > crack maintenance-wise. Having a 5.4 I-pipe in reach definitely relaxes our pressure to move the core over dovetail and do many necessary and reasonable refactoring along that. 5.10 will most likely by the next LTS, and that is what the dovetail porting is targeting. > > Out of curiosity, are there teams at Intel/Siemens planning for this > already? Intel stepped up to work with the I-pipe 5.4 port for x86 and would also like to support with the dovetail work. At Siemens we are looking at the y2038 conversion and the dovetail baseline. For the former topic Chensong is joining us. > > Also, are there any discussions about what the next major Xenomai > release (i.e. post-3.1) should aim at, particularly in the context of > upstream's plans to merge the
Re: Useless dovetail hacks
Jan Kiszka via Xenomai writes: > Hi all, > > to permit sharing the work of porting Xenomai over dovetail, I finally > pushed my baseline hacks to [1]. You can "use" that on [2] (use > fa1e9ba5e822, 0d68e5607286 leaks evl bits and is broken) Fixed on top of [2] now, thanks. > just like you > would for an I-pipe kernel (prepare-kernel.sh). The thing builds for me, > it even starts and gives a prompt, but that's because of > > [1.186025] [Xenomai] init failed, code -19 > > All the timing stuff is not mapped yet. Like a lot of other things. ETIME... > This rough enumeration of what would change in Cobalt as a result of rebasing on Dovetail still applies: https://xenomai.org/pipermail/xenomai/2020-February/042488.html To summarize this, a significant issue would involve switching the xntimer abstraction to nanosecs, dropping all references to the internal time unit which may be used by the clock and timer devices (e.g. TSC on x86, free running counters from assorted ARM/aarch64 timers). Overall, switching to Dovetail entails disabling a significant amount of low-level code from Cobalt, which implements features the former already handles (like core context switch support, fpu sharing between execution stages, shared interrupt support [in xnintr] and reading the POSIX clocks from the real-time context via the generic vDSO). > Please raise your hand when you'd like to join this endeavor, then we > can discuss a split-up of tasks. Next steps would be: > > - make it initialize dovetail properly and activate Xenomai > - hack on it until Xenomai tasks work properly > - look at the result an decide how to integrate with I-pipe or whether > to make this Xenomai 3.2 without any I-pipe support Assuming you meant that an option might be to enable Xenomai 3.1 to run over Dovetail, I would say that a Dovetail-based Cobalt core implies Xenomai 3.2+ instead, because 3.1.x is deemed stable, therefore the ABI changes involved in such a transition should not make their way into the stable tree. There is also the issue of ppc32 and x86_32, which Dovetail does not support. Although having both ABIs live side-by-side in a way that would maintain backward compat with I-pipe kernels might be done, the result would not be pretty implementation-wise: redundancies and ugly wrappings to be expected in libcobalt, and two set of build settings for the latter depending on which ABI is targeted to avoid indirect calls all over the place. Which would also require having separate sets of user-space libraries, specifically built for one IRQ pipeline core or the other, adding to the confusion. On a more general note, isn't the issue about which should be the final kernel release the project would pledge to support with Xenomai 3.1.x? As of today, Xenomai 3.1 is (almost) running kernel 5.4 LTS over the I-pipe, at least on x86. If things go as usual upstream, the next LTS kernel is going to be post-5.7, which means the effort in porting the I-pipe to the next LTS release may be quite significant, with many conflicts to expect between the upstream changes and the pipeline code starting from kernel 5.8, particularly for x86. For this reason, keeping the Cobalt core compatible with the I-pipe beyond kernel 5.4, adding support for Dovetail the right way in the meantime seems a hard nut to crack maintenance-wise. Out of curiosity, are there teams at Intel/Siemens planning for this already? Also, are there any discussions about what the next major Xenomai release (i.e. post-3.1) should aim at, particularly in the context of upstream's plans to merge the last preempt-rt bits in the 5.10 timeframe? Should this major Xenomai release be exclusively about solving the I-pipe maintenance issue by rebasing Cobalt over Dovetail? Could this be also an opportunity to have an all-out conversation about the best way to ensure Xenomai stays relevant in the years to come as a enabler for a particular class of real-time applications? Are there any discussions about the scope and purpose of what Xenomai as a system should provide? such as (and not exclusively): - is API emulation of legacy RTOS (VxWorks, pSOS) still relevant in this day and age? Corollary: is allowing people to develop their own flavor of whatever real-time API something Xenomai should still provide support for. - how to solve the general issue of driver bit rotting over Cobalt/RTDM? (e.g. can, uart, spi, rtnet) - with hindsight, is maintaining a unified API support between the I-pipe and preempt-rt environments via libcopperplate still relevant, compared to the complexity this brings into the code base? Generally speaking, should Xenomai still pledge to support both environments transparently (which is still not fully the case in absence of a modern native RTDM implementation), or should the project exclusively (re-)focus on its dual kernel technology instead? - should an orphaned stack like Analogy be kept in, knowing that nobody really cared over
Re: [PATCH v4] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
On 11.09.20 11:43, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for the
> 'oflag' parameter to the functionality of open()/open64(). They may be used
> when
> the macro _FORTIFY_SOURCE is defined when compiling the application code.
> Added
> these wrappers to cover those cases.
>
> If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
> declarations for __open_2() and __open64_2() are not available.
> __STD(__open_2(...)) will not link in this case (would be a very special
> use case anyway?).
>
> Signed-off-by: Jan Leupold
> ---
> include/cobalt/fcntl.h | 4
> lib/cobalt/cobalt.wrappers | 2 ++
> lib/cobalt/rtdm.c | 32
> lib/cobalt/wrappers.c | 12
> 4 files changed, 50 insertions(+)
>
> diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
> index d54989389..f1052c28d 100644
> --- a/include/cobalt/fcntl.h
> +++ b/include/cobalt/fcntl.h
> @@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
>
> COBALT_DECL(int, open64(const char *path, int oflag, ...));
>
> +COBALT_DECL(int, __open_2(const char *path, int oflag));
> +
> +COBALT_DECL(int, __open64_2(const char *path, int oflag));
> +
> COBALT_DECL(int, fcntl(int fd, int cmd, ...));
>
> #ifdef __cplusplus
> diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
> index f63a170f8..0e954764d 100644
> --- a/lib/cobalt/cobalt.wrappers
> +++ b/lib/cobalt/cobalt.wrappers
> @@ -54,6 +54,8 @@
> --wrap mq_notify
> --wrap open
> --wrap open64
> +--wrap __open_2
> +--wrap __open64_2
> --wrap socket
> --wrap close
> --wrap ioctl
> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
> index 9f3dcd25f..f3fb5d411 100644
> --- a/lib/cobalt/rtdm.c
> +++ b/lib/cobalt/rtdm.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag,
> ...))
> return do_open(path, oflag | O_LARGEFILE, mode);
> }
>
> +COBALT_IMPL(int, __open_2, (const char *path, int oflag))
> +{
> + /* __open_2() from glibc adds a runtime precondition test for the
> 'oflag'
> + * parameter to the functionality of open(). It may be used when the
> macro
> + * _FORTIFY_SOURCE is defined when compiling the application code.
> + */
> + if (__OPEN_NEEDS_MODE(oflag)) {
> + const char *msg =
> + "invalid open call: O_CREAT or O_TMPFILE without
> mode\n";
> + ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
> + (void)n;
> + abort();
> + }
> +
> + return do_open(path, oflag, 0);
> +}
> +
> +COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
> +{
> + /* just like __open_2() and open64() */
> + if (__OPEN_NEEDS_MODE(oflag)) {
> + const char *msg =
> + "invalid open64 call: O_CREAT or O_TMPFILE without
> mode\n";
> + ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
> + (void)n;
> + abort();
> + }
> +
> + return do_open(path, oflag | O_LARGEFILE, 0);
> +}
> +
> COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int
> protocol))
> {
> int s;
> diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
> index ed8fbaf16..860b26020 100644
> --- a/lib/cobalt/wrappers.c
> +++ b/lib/cobalt/wrappers.c
> @@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
> }
> #endif
>
> +#if __USE_FORTIFY_LEVEL > 0
> +__weak int __real___open_2(const char *path, int oflag)
> +{
> + return __open_2(path, oflag);
> +}
> +
> +__weak int __real___open64_2(const char *path, int oflag)
> +{
> + return __open64_2(path, oflag);
> +}
> +#endif // __USE_FORTIFY_LEVEL > 0
> +
> __weak
> int __real_socket(int protocol_family, int socket_type, int protocol)
> {
>
Thanks, applied to next (old one dropped).
Jan
PS: Bonus for adding "From: Jan Leupold "
at the top of the commit message in any future patches.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
[PATCH v4] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
__open_2() and __open64_2() from glibc add runtime precondition tests for the
'oflag' parameter to the functionality of open()/open64(). They may be used when
the macro _FORTIFY_SOURCE is defined when compiling the application code. Added
these wrappers to cover those cases.
If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
declarations for __open_2() and __open64_2() are not available.
__STD(__open_2(...)) will not link in this case (would be a very special
use case anyway?).
Signed-off-by: Jan Leupold
---
include/cobalt/fcntl.h | 4
lib/cobalt/cobalt.wrappers | 2 ++
lib/cobalt/rtdm.c | 32
lib/cobalt/wrappers.c | 12
4 files changed, 50 insertions(+)
diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
index d54989389..f1052c28d 100644
--- a/include/cobalt/fcntl.h
+++ b/include/cobalt/fcntl.h
@@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
COBALT_DECL(int, open64(const char *path, int oflag, ...));
+COBALT_DECL(int, __open_2(const char *path, int oflag));
+
+COBALT_DECL(int, __open64_2(const char *path, int oflag));
+
COBALT_DECL(int, fcntl(int fd, int cmd, ...));
#ifdef __cplusplus
diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
index f63a170f8..0e954764d 100644
--- a/lib/cobalt/cobalt.wrappers
+++ b/lib/cobalt/cobalt.wrappers
@@ -54,6 +54,8 @@
--wrap mq_notify
--wrap open
--wrap open64
+--wrap __open_2
+--wrap __open64_2
--wrap socket
--wrap close
--wrap ioctl
diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 9f3dcd25f..f3fb5d411 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
return do_open(path, oflag | O_LARGEFILE, mode);
}
+COBALT_IMPL(int, __open_2, (const char *path, int oflag))
+{
+ /* __open_2() from glibc adds a runtime precondition test for the
'oflag'
+* parameter to the functionality of open(). It may be used when the
macro
+* _FORTIFY_SOURCE is defined when compiling the application code.
+*/
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag, 0);
+}
+
+COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
+{
+ /* just like __open_2() and open64() */
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open64 call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag | O_LARGEFILE, 0);
+}
+
COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int protocol))
{
int s;
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index ed8fbaf16..860b26020 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
}
#endif
+#if __USE_FORTIFY_LEVEL > 0
+__weak int __real___open_2(const char *path, int oflag)
+{
+ return __open_2(path, oflag);
+}
+
+__weak int __real___open64_2(const char *path, int oflag)
+{
+ return __open64_2(path, oflag);
+}
+#endif // __USE_FORTIFY_LEVEL > 0
+
__weak
int __real_socket(int protocol_family, int socket_type, int protocol)
{
--
2.20.1
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
[PATCH v3] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
__open_2() and __open64_2() from glibc add runtime precondition tests for the
'oflag' parameter to the functionality of open()/open64(). They may be used when
the macro _FORTIFY_SOURCE is defined when compiling the application code. Added
these wrappers to cover those cases.
If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
declarations for __open_2() and __open64_2() are not available.
__STD(__open_2(...)) will not link in this case (would be a very special
use case anyway?).
Signed-off-by: Jan Leupold
---
include/cobalt/fcntl.h | 4
lib/cobalt/cobalt.wrappers | 2 ++
lib/cobalt/rtdm.c | 32
lib/cobalt/wrappers.c | 12
4 files changed, 50 insertions(+)
diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
index d54989389..f1052c28d 100644
--- a/include/cobalt/fcntl.h
+++ b/include/cobalt/fcntl.h
@@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
COBALT_DECL(int, open64(const char *path, int oflag, ...));
+COBALT_DECL(int, __open_2(const char *path, int oflag));
+
+COBALT_DECL(int, __open64_2(const char *path, int oflag));
+
COBALT_DECL(int, fcntl(int fd, int cmd, ...));
#ifdef __cplusplus
diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
index f63a170f8..0e954764d 100644
--- a/lib/cobalt/cobalt.wrappers
+++ b/lib/cobalt/cobalt.wrappers
@@ -54,6 +54,8 @@
--wrap mq_notify
--wrap open
--wrap open64
+--wrap __open_2
+--wrap __open64_2
--wrap socket
--wrap close
--wrap ioctl
diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 9f3dcd25f..83cc699ed 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
return do_open(path, oflag | O_LARGEFILE, mode);
}
+COBALT_IMPL(int, __open_2, (const char *path, int oflag))
+{
+ /* __open_2() from glibc adds a runtime precondition test for the
'oflag'
+* parameter to the functionality of open(). It may be used when the
macro
+* _FORTIFY_SOURCE is defined when compiling the application code.
+*/
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag, 0);
+}
+
+COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
+{
+ /* just like __open_2() and open64() */
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open64 call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag | O_LARGEFILE, 0);
+}
+
COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int protocol))
{
int s;
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index ed8fbaf16..860b26020 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
}
#endif
+#if __USE_FORTIFY_LEVEL > 0
+__weak int __real___open_2(const char *path, int oflag)
+{
+ return __open_2(path, oflag);
+}
+
+__weak int __real___open64_2(const char *path, int oflag)
+{
+ return __open64_2(path, oflag);
+}
+#endif // __USE_FORTIFY_LEVEL > 0
+
__weak
int __real_socket(int protocol_family, int socket_type, int protocol)
{
--
2.20.1
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
[PATCH v3] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
__open_2() and __open64_2() from glibc add runtime precondition tests for the
'oflag' parameter to the functionality of open()/open64(). They may be used when
the macro _FORTIFY_SOURCE is defined when compiling the application code. Added
these wrappers to cover those cases.
If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
declarations for __open_2() and __open64_2() are not available.
__STD(__open_2(...)) will not link in this case (would be a very special
use case anyway?).
Signed-off-by: Jan Leupold
---
include/cobalt/fcntl.h | 4
lib/cobalt/cobalt.wrappers | 2 ++
lib/cobalt/rtdm.c | 32
lib/cobalt/wrappers.c | 12
4 files changed, 50 insertions(+)
diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
index d54989389..f1052c28d 100644
--- a/include/cobalt/fcntl.h
+++ b/include/cobalt/fcntl.h
@@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
COBALT_DECL(int, open64(const char *path, int oflag, ...));
+COBALT_DECL(int, __open_2(const char *path, int oflag));
+
+COBALT_DECL(int, __open64_2(const char *path, int oflag));
+
COBALT_DECL(int, fcntl(int fd, int cmd, ...));
#ifdef __cplusplus
diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
index f63a170f8..0e954764d 100644
--- a/lib/cobalt/cobalt.wrappers
+++ b/lib/cobalt/cobalt.wrappers
@@ -54,6 +54,8 @@
--wrap mq_notify
--wrap open
--wrap open64
+--wrap __open_2
+--wrap __open64_2
--wrap socket
--wrap close
--wrap ioctl
diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 9f3dcd25f..83cc699ed 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
return do_open(path, oflag | O_LARGEFILE, mode);
}
+COBALT_IMPL(int, __open_2, (const char *path, int oflag))
+{
+ /* __open_2() from glibc adds a runtime precondition test for the
'oflag'
+* parameter to the functionality of open(). It may be used when the
macro
+* _FORTIFY_SOURCE is defined when compiling the application code.
+*/
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = __STD(write(STDERR_FILENO, msg, strlen(msg)));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag, 0);
+}
+
+COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
+{
+ /* just like __open_2() and open64() */
+ if (__OPEN_NEEDS_MODE(oflag)) {
+ const char *msg =
+ "invalid open64 call: O_CREAT or O_TMPFILE without
mode\n";
+ ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
+ (void)n;
+ abort();
+ }
+
+ return do_open(path, oflag | O_LARGEFILE, 0);
+}
+
COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int protocol))
{
int s;
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index ed8fbaf16..860b26020 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
}
#endif
+#if __USE_FORTIFY_LEVEL > 0
+__weak int __real___open_2(const char *path, int oflag)
+{
+ return __open_2(path, oflag);
+}
+
+__weak int __real___open64_2(const char *path, int oflag)
+{
+ return __open64_2(path, oflag);
+}
+#endif // __USE_FORTIFY_LEVEL > 0
+
__weak
int __real_socket(int protocol_family, int socket_type, int protocol)
{
--
2.20.1
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
Re: [PATCH 5/6] x86/ipipe: fix build with CONFIG_X86_UV enabled
On 07.09.20 17:18, Philippe Gerum wrote: > > Philippe Gerum writes: > >> Jan Kiszka writes: >> >>> On 07.09.20 15:09, Philippe Gerum wrote: From: Philippe Gerum Signed-off-by: Philippe Gerum --- arch/x86/kernel/ipipe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c index 3f3afcecc1b9..c5ebfdf2dfb3 100644 --- a/arch/x86/kernel/ipipe.c +++ b/arch/x86/kernel/ipipe.c @@ -72,6 +72,7 @@ void smp_irq_move_cleanup_interrupt(struct pt_regs *regs); void smp_reboot_interrupt(void); void smp_thermal_interrupt(struct pt_regs *regs); void smp_threshold_interrupt(struct pt_regs *regs); +void uv_bau_message_interrupt(struct pt_regs *regs); void __ipipe_do_IRQ(unsigned int irq, void *cookie); >>> >>> IIRC, I broke that intentionally. There is more needed, and no one >>> should get something building but subtly not working. But we may better do >>> >>> depends on !IPIPE >>> >> >> Indeed, otherwise plain build tests with e.g. allyesconfig fail miserably. > > I meant "allnoconfig" of course, but you get the point. > I've added https://gitlab.denx.de/Xenomai/ipipe-x86/-/commit/fe5928a3ea7d24eaad0e4a293e25bd1463312c17 instead to 4.19-x86 All other patches merged (and now part of ipipe-core-4.19.140-cip33-x86-14), the generic ones also the ipipe-noarch. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
Please consider for v3:
On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for the
> 'oflag' parameter to the functionality of open()/open64(). They may be used
> when
> the macro _FORTIFY_SOURCE is defined when compiling the application code.
> Added
> these wrappers to cover those cases.
>
> Signed-off-by: Jan Leupold
> ---
> include/cobalt/fcntl.h | 4
> lib/cobalt/cobalt.wrappers | 2 ++
> lib/cobalt/rtdm.c | 32
> lib/cobalt/wrappers.c | 12
> 4 files changed, 50 insertions(+)
>
> diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
> index d54989389..f1052c28d 100644
> --- a/include/cobalt/fcntl.h
> +++ b/include/cobalt/fcntl.h
> @@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
>
> COBALT_DECL(int, open64(const char *path, int oflag, ...));
>
> +COBALT_DECL(int, __open_2(const char *path, int oflag));
> +
> +COBALT_DECL(int, __open64_2(const char *path, int oflag));
> +
> COBALT_DECL(int, fcntl(int fd, int cmd, ...));
>
> #ifdef __cplusplus
> diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
> index f63a170f8..0e954764d 100644
> --- a/lib/cobalt/cobalt.wrappers
> +++ b/lib/cobalt/cobalt.wrappers
> @@ -54,6 +54,8 @@
> --wrap mq_notify
> --wrap open
> --wrap open64
> +--wrap __open_2
> +--wrap __open64_2
> --wrap socket
> --wrap close
> --wrap ioctl
> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
> index 9f3dcd25f..80d08b18f 100644
> --- a/lib/cobalt/rtdm.c
> +++ b/lib/cobalt/rtdm.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag,
> ...))
> return do_open(path, oflag | O_LARGEFILE, mode);
> }
>
> +COBALT_IMPL(int, __open_2, (const char *path, int oflag))
> +{
> +/* __open_2() from glibc adds a runtime precondition test for the 'oflag'
> + * parameter to the functionality of open(). It may be used when the
> macro
> + * _FORTIFY_SOURCE is defined when compiling the application code.
> + */
> +if (__OPEN_NEEDS_MODE(oflag)) {
> +const char* msg =
> +"invalid open call: O_CREAT or O_TMPFILE without mode\n";
> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
__STD(write())
> +(void) n;
> +abort();
> +}
> +
> + return do_open(path, oflag, 0);
> +}
> +
> +COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
> +{
> +/* just like __open_2() and open64() */
> +if (__OPEN_NEEDS_MODE(oflag)) {
> +const char* msg =
> +"invalid open64 call: O_CREAT or O_TMPFILE without mode\n";
> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
> +(void) n;
> +abort();
> +}
Indention is broken, here and above. Make sure to use tabs consistently.
Jan
> +
> + return do_open(path, oflag | O_LARGEFILE, 0);
> +}
> +
> COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int
> protocol))
> {
> int s;
> diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
> index ed8fbaf16..5d86607de 100644
> --- a/lib/cobalt/wrappers.c
> +++ b/lib/cobalt/wrappers.c
> @@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
> }
> #endif
>
> +__weak
> +int __real___open_2(const char *path, int oflag)
> +{
> +return __open_2(path, oflag);
> +}
> +
> +__weak
> +int __real___open64_2(const char *path, int oflag)
> +{
> +return __open64_2(path, oflag);
> +}
> +
> __weak
> int __real_socket(int protocol_family, int socket_type, int protocol)
> {
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH] lib/cobalt: only compile __real___open[64]_2 wrappers if fortified
On 11.09.20 10:32, Jan Leupold via Xenomai wrote:
> If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
> declarations for __open_2() and __open64_2() are not available.
> __STD(__open_2(...)) will not link in this case (would be a very special
> use case anyway?).
>
That seems like a reasonable approach.
BUT: This must be part of v3 of your patch (version your patches,
please). And there are two more things in that patch which I missed
yesterday. Will comment in the original thread.
Jan
> Signed-off-by: Jan Leupold
> ---
> lib/cobalt/wrappers.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
> index 5d86607de..5ff6b63bc 100644
> --- a/lib/cobalt/wrappers.c
> +++ b/lib/cobalt/wrappers.c
> @@ -205,6 +205,7 @@ int __real_open64(const char *path, int oflag, ...)
> }
> #endif
>
> +#if __USE_FORTIFY_LEVEL > 0
> __weak
> int __real___open_2(const char *path, int oflag)
> {
> @@ -216,6 +217,7 @@ int __real___open64_2(const char *path, int oflag)
> {
> return __open64_2(path, oflag);
> }
> +#endif // __USE_FORTIFY_LEVEL > 0
>
> __weak
> int __real_socket(int protocol_family, int socket_type, int protocol)
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
[PATCH] lib/cobalt: only compile __real___open[64]_2 wrappers if fortified
If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
declarations for __open_2() and __open64_2() are not available.
__STD(__open_2(...)) will not link in this case (would be a very special
use case anyway?).
Signed-off-by: Jan Leupold
---
lib/cobalt/wrappers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index 5d86607de..5ff6b63bc 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -205,6 +205,7 @@ int __real_open64(const char *path, int oflag, ...)
}
#endif
+#if __USE_FORTIFY_LEVEL > 0
__weak
int __real___open_2(const char *path, int oflag)
{
@@ -216,6 +217,7 @@ int __real___open64_2(const char *path, int oflag)
{
return __open64_2(path, oflag);
}
+#endif // __USE_FORTIFY_LEVEL > 0
__weak
int __real_socket(int protocol_family, int socket_type, int protocol)
--
2.20.1
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
Re: [PATCH] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
Am 11.09.20 um 09:55 schrieb Jan Kiszka:
> On 11.09.20 08:22, Jan Leupold via Xenomai wrote:
>> Am 10.09.20 um 18:27 schrieb Jan Kiszka:
>>> On 10.09.20 18:14, Jan Kiszka via Xenomai wrote:
On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for
> the
> 'oflag' parameter to the functionality of open()/open64(). They may be
> used when
> the macro _FORTIFY_SOURCE is defined when compiling the application code.
> Added
> these wrappers to cover those cases.
>
> Signed-off-by: Jan Leupold
> ---
> include/cobalt/fcntl.h | 4
> lib/cobalt/cobalt.wrappers | 2 ++
> lib/cobalt/rtdm.c | 32
> lib/cobalt/wrappers.c | 12
> 4 files changed, 50 insertions(+)
>
> diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
> index d54989389..f1052c28d 100644
> --- a/include/cobalt/fcntl.h
> +++ b/include/cobalt/fcntl.h
> @@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag,
> ...));
>
> COBALT_DECL(int, open64(const char *path, int oflag, ...));
>
> +COBALT_DECL(int, __open_2(const char *path, int oflag));
> +
> +COBALT_DECL(int, __open64_2(const char *path, int oflag));
> +
> COBALT_DECL(int, fcntl(int fd, int cmd, ...));
>
> #ifdef __cplusplus
> diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
> index f63a170f8..0e954764d 100644
> --- a/lib/cobalt/cobalt.wrappers
> +++ b/lib/cobalt/cobalt.wrappers
> @@ -54,6 +54,8 @@
> --wrap mq_notify
> --wrap open
> --wrap open64
> +--wrap __open_2
> +--wrap __open64_2
> --wrap socket
> --wrap close
> --wrap ioctl
> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
> index 9f3dcd25f..80d08b18f 100644
> --- a/lib/cobalt/rtdm.c
> +++ b/lib/cobalt/rtdm.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag,
> ...))
> return do_open(path, oflag | O_LARGEFILE, mode);
> }
>
> +COBALT_IMPL(int, __open_2, (const char *path, int oflag))
> +{
> +/* __open_2() from glibc adds a runtime precondition test for the
> 'oflag'
> + * parameter to the functionality of open(). It may be used when the
> macro
> + * _FORTIFY_SOURCE is defined when compiling the application code.
> + */
> +if (__OPEN_NEEDS_MODE(oflag)) {
> +const char* msg =
> +"invalid open call: O_CREAT or O_TMPFILE without mode\n";
> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
> +(void) n;
> +abort();
> +}
> +
> + return do_open(path, oflag, 0);
> +}
> +
> +COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
> +{
> +/* just like __open_2() and open64() */
> +if (__OPEN_NEEDS_MODE(oflag)) {
> +const char* msg =
> +"invalid open64 call: O_CREAT or O_TMPFILE without mode\n";
> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
> +(void) n;
> +abort();
> +}
> +
> + return do_open(path, oflag | O_LARGEFILE, 0);
> +}
> +
> COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int
> protocol))
> {
> int s;
> diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
> index ed8fbaf16..5d86607de 100644
> --- a/lib/cobalt/wrappers.c
> +++ b/lib/cobalt/wrappers.c
> @@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
> }
> #endif
>
> +__weak
> +int __real___open_2(const char *path, int oflag)
> +{
> +return __open_2(path, oflag);
> +}
> +
> +__weak
> +int __real___open64_2(const char *path, int oflag)
> +{
> +return __open64_2(path, oflag);
> +}
> +
> __weak
> int __real_socket(int protocol_family, int socket_type, int protocol)
> {
>
Thanks, applied to next.
>>>
>>> Currently stressing multiple CI infrastructures, and our internal one
>>> already revealed that you will soon see red lights in some jobs here:
>>>
>>> https://gitlab.denx.de/Xenomai/xenomai/-/pipelines/4644
>>>
>>> CC libcobalt_la-wrappers.lo
>>> wrappers.c: In function '__real___open_2':
>>> wrappers.c:211:12: error: implicit declaration of function '__open_2'; did
>>> you mean 'openat'? [-Werror=implicit-function-declaration]
>>> return __open_2(path, oflag);
>>> ^~~~
>>> openat
>>> wrappers.c: In function '__real___open64_2':
>>> wrappers.c:217:12: error: implicit declaration of function '__open64_2';
>>>
Re: [PATCH] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
On 11.09.20 08:22, Jan Leupold via Xenomai wrote:
> Am 10.09.20 um 18:27 schrieb Jan Kiszka:
>> On 10.09.20 18:14, Jan Kiszka via Xenomai wrote:
>>> On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
__open_2() and __open64_2() from glibc add runtime precondition tests for
the
'oflag' parameter to the functionality of open()/open64(). They may be
used when
the macro _FORTIFY_SOURCE is defined when compiling the application code.
Added
these wrappers to cover those cases.
Signed-off-by: Jan Leupold
---
include/cobalt/fcntl.h | 4
lib/cobalt/cobalt.wrappers | 2 ++
lib/cobalt/rtdm.c | 32
lib/cobalt/wrappers.c | 12
4 files changed, 50 insertions(+)
diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
index d54989389..f1052c28d 100644
--- a/include/cobalt/fcntl.h
+++ b/include/cobalt/fcntl.h
@@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag,
...));
COBALT_DECL(int, open64(const char *path, int oflag, ...));
+COBALT_DECL(int, __open_2(const char *path, int oflag));
+
+COBALT_DECL(int, __open64_2(const char *path, int oflag));
+
COBALT_DECL(int, fcntl(int fd, int cmd, ...));
#ifdef __cplusplus
diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
index f63a170f8..0e954764d 100644
--- a/lib/cobalt/cobalt.wrappers
+++ b/lib/cobalt/cobalt.wrappers
@@ -54,6 +54,8 @@
--wrap mq_notify
--wrap open
--wrap open64
+--wrap __open_2
+--wrap __open64_2
--wrap socket
--wrap close
--wrap ioctl
diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
index 9f3dcd25f..80d08b18f 100644
--- a/lib/cobalt/rtdm.c
+++ b/lib/cobalt/rtdm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag,
...))
return do_open(path, oflag | O_LARGEFILE, mode);
}
+COBALT_IMPL(int, __open_2, (const char *path, int oflag))
+{
+/* __open_2() from glibc adds a runtime precondition test for the
'oflag'
+ * parameter to the functionality of open(). It may be used when the
macro
+ * _FORTIFY_SOURCE is defined when compiling the application code.
+ */
+if (__OPEN_NEEDS_MODE(oflag)) {
+const char* msg =
+"invalid open call: O_CREAT or O_TMPFILE without mode\n";
+ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
+(void) n;
+abort();
+}
+
+ return do_open(path, oflag, 0);
+}
+
+COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
+{
+/* just like __open_2() and open64() */
+if (__OPEN_NEEDS_MODE(oflag)) {
+const char* msg =
+"invalid open64 call: O_CREAT or O_TMPFILE without mode\n";
+ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
+(void) n;
+abort();
+}
+
+ return do_open(path, oflag | O_LARGEFILE, 0);
+}
+
COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int
protocol))
{
int s;
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index ed8fbaf16..5d86607de 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
}
#endif
+__weak
+int __real___open_2(const char *path, int oflag)
+{
+return __open_2(path, oflag);
+}
+
+__weak
+int __real___open64_2(const char *path, int oflag)
+{
+return __open64_2(path, oflag);
+}
+
__weak
int __real_socket(int protocol_family, int socket_type, int protocol)
{
>>>
>>> Thanks, applied to next.
>>>
>>
>> Currently stressing multiple CI infrastructures, and our internal one
>> already revealed that you will soon see red lights in some jobs here:
>>
>> https://gitlab.denx.de/Xenomai/xenomai/-/pipelines/4644
>>
>> CC libcobalt_la-wrappers.lo
>> wrappers.c: In function '__real___open_2':
>> wrappers.c:211:12: error: implicit declaration of function '__open_2'; did
>> you mean 'openat'? [-Werror=implicit-function-declaration]
>> return __open_2(path, oflag);
>> ^~~~
>> openat
>> wrappers.c: In function '__real___open64_2':
>> wrappers.c:217:12: error: implicit declaration of function '__open64_2'; did
>> you mean 'open64'? [-Werror=implicit-function-declaration]
>> return __open64_2(path, oflag);
>> ^~
>> open64
>> cc1: all warnings being treated
Re: [PATCH] lib/cobalt: Wrap __open_2/__open64_2 to support _FORTIFY_SOURCE
Am 10.09.20 um 18:27 schrieb Jan Kiszka:
> On 10.09.20 18:14, Jan Kiszka via Xenomai wrote:
>> On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
>>> __open_2() and __open64_2() from glibc add runtime precondition tests for
>>> the
>>> 'oflag' parameter to the functionality of open()/open64(). They may be used
>>> when
>>> the macro _FORTIFY_SOURCE is defined when compiling the application code.
>>> Added
>>> these wrappers to cover those cases.
>>>
>>> Signed-off-by: Jan Leupold
>>> ---
>>> include/cobalt/fcntl.h | 4
>>> lib/cobalt/cobalt.wrappers | 2 ++
>>> lib/cobalt/rtdm.c | 32
>>> lib/cobalt/wrappers.c | 12
>>> 4 files changed, 50 insertions(+)
>>>
>>> diff --git a/include/cobalt/fcntl.h b/include/cobalt/fcntl.h
>>> index d54989389..f1052c28d 100644
>>> --- a/include/cobalt/fcntl.h
>>> +++ b/include/cobalt/fcntl.h
>>> @@ -31,6 +31,10 @@ COBALT_DECL(int, open(const char *path, int oflag, ...));
>>>
>>> COBALT_DECL(int, open64(const char *path, int oflag, ...));
>>>
>>> +COBALT_DECL(int, __open_2(const char *path, int oflag));
>>> +
>>> +COBALT_DECL(int, __open64_2(const char *path, int oflag));
>>> +
>>> COBALT_DECL(int, fcntl(int fd, int cmd, ...));
>>>
>>> #ifdef __cplusplus
>>> diff --git a/lib/cobalt/cobalt.wrappers b/lib/cobalt/cobalt.wrappers
>>> index f63a170f8..0e954764d 100644
>>> --- a/lib/cobalt/cobalt.wrappers
>>> +++ b/lib/cobalt/cobalt.wrappers
>>> @@ -54,6 +54,8 @@
>>> --wrap mq_notify
>>> --wrap open
>>> --wrap open64
>>> +--wrap __open_2
>>> +--wrap __open64_2
>>> --wrap socket
>>> --wrap close
>>> --wrap ioctl
>>> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
>>> index 9f3dcd25f..80d08b18f 100644
>>> --- a/lib/cobalt/rtdm.c
>>> +++ b/lib/cobalt/rtdm.c
>>> @@ -23,6 +23,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -94,6 +95,37 @@ COBALT_IMPL(int, open64, (const char *path, int oflag,
>>> ...))
>>> return do_open(path, oflag | O_LARGEFILE, mode);
>>> }
>>>
>>> +COBALT_IMPL(int, __open_2, (const char *path, int oflag))
>>> +{
>>> +/* __open_2() from glibc adds a runtime precondition test for the
>>> 'oflag'
>>> + * parameter to the functionality of open(). It may be used when the
>>> macro
>>> + * _FORTIFY_SOURCE is defined when compiling the application code.
>>> + */
>>> +if (__OPEN_NEEDS_MODE(oflag)) {
>>> +const char* msg =
>>> +"invalid open call: O_CREAT or O_TMPFILE without mode\n";
>>> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
>>> +(void) n;
>>> +abort();
>>> +}
>>> +
>>> + return do_open(path, oflag, 0);
>>> +}
>>> +
>>> +COBALT_IMPL(int, __open64_2, (const char *path, int oflag))
>>> +{
>>> +/* just like __open_2() and open64() */
>>> +if (__OPEN_NEEDS_MODE(oflag)) {
>>> +const char* msg =
>>> +"invalid open64 call: O_CREAT or O_TMPFILE without mode\n";
>>> +ssize_t n = write(STDERR_FILENO, msg, strlen(msg));
>>> +(void) n;
>>> +abort();
>>> +}
>>> +
>>> + return do_open(path, oflag | O_LARGEFILE, 0);
>>> +}
>>> +
>>> COBALT_IMPL(int, socket, (int protocol_family, int socket_type, int
>>> protocol))
>>> {
>>> int s;
>>> diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
>>> index ed8fbaf16..5d86607de 100644
>>> --- a/lib/cobalt/wrappers.c
>>> +++ b/lib/cobalt/wrappers.c
>>> @@ -205,6 +205,18 @@ int __real_open64(const char *path, int oflag, ...)
>>> }
>>> #endif
>>>
>>> +__weak
>>> +int __real___open_2(const char *path, int oflag)
>>> +{
>>> +return __open_2(path, oflag);
>>> +}
>>> +
>>> +__weak
>>> +int __real___open64_2(const char *path, int oflag)
>>> +{
>>> +return __open64_2(path, oflag);
>>> +}
>>> +
>>> __weak
>>> int __real_socket(int protocol_family, int socket_type, int protocol)
>>> {
>>>
>>
>> Thanks, applied to next.
>>
>
> Currently stressing multiple CI infrastructures, and our internal one
> already revealed that you will soon see red lights in some jobs here:
>
> https://gitlab.denx.de/Xenomai/xenomai/-/pipelines/4644
>
> CC libcobalt_la-wrappers.lo
> wrappers.c: In function '__real___open_2':
> wrappers.c:211:12: error: implicit declaration of function '__open_2'; did
> you mean 'openat'? [-Werror=implicit-function-declaration]
> return __open_2(path, oflag);
> ^~~~
> openat
> wrappers.c: In function '__real___open64_2':
> wrappers.c:217:12: error: implicit declaration of function '__open64_2'; did
> you mean 'open64'? [-Werror=implicit-function-declaration]
> return __open64_2(path, oflag);
> ^~
> open64
> cc1: all warnings being treated as errors
>
> We need to account for non-fortified setups.
I see several ways to handle this:
1. put both functions in a separate source file, which is always compilied
with _FORTIFY_SOURCE=2.
[I-PIPE] ipipe-core-4.19.140-cip33-x86-14 released
Download URL: https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.140-cip33-x86-14.patch Repository: https://git.xenomai.org/ipipe-x86 Release tag: ipipe-core-4.19.140-cip33-x86-14
