So any update on this.
Do you have something similar to patchwork to keep up on those loose
email-threads?
Norbert
> -----Original Message-----
> From: Xenomai <xenomai-boun...@xenomai.org> On Behalf Of Norbert
> Lange
> Sent: Freitag, 26. Oktober 2018 18:36
> To: jan.kis...@siemens.com
> Cc: Xenomai <xenomai@xenomai.org>
> Subject: Re: improve and provide a header for bootstrapping
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Am Fr., 26. Okt. 2018 um 15:48 Uhr schrieb Jan Kiszka
> <jan.kis...@siemens.com>:
> >
> > On 23.10.18 16:16, Norbert Lange wrote:
> > > Hello,
> > >
> > > the following patches allow a variety of options additional to the
> > > linker magic involved for hijacking the aplications main function.
> > >
> > > the original method will still continue to work, differences are
> > >
> > > * the code dealing with retrieving the commandline arguments
> > > is moved into libcobale/libmercury. Making the necessary per-
> application
> > > code much smaller.
> > >
> > > * the implementation was moved into a header, with several macros
> > > controlling functionality (not everyone wants to define a main
> function).
> > >
> > >
> > > The approach I use personally is to compile and link my own
> > > bootstrap code, which is preferable in many build systems as
> > > source-files are understood while objects files generally need some
> > > special care. (And it cant hurt if the compiler flags match exactly).
> > >
> > > As example:
> > >
> > > ----- add this to your file containing main
> > >
> > > int xenomai_init_getargv(int *argc, char *const** argv);
> > >
> > > int main(int argc, char *const argv[]) { #if defined(__COBALT__) ||
> > > defined(__MERCURY__)
> > > xenomai_init_getargv(&argc, &argv); #endif
> > > ....
> > > }
> > >
> > > ----- create another file, lets call it mybootstrap.c
> > >
> > > #define _XENOMAI_BOOTSTRAP_GLIBC_CONSTRUCTORS
> > > #include <xenomai/bootstrap-template.h>
> > >
> > > ----------------------------------------------
> > >
> > > Norbert
> > >
> > > [PATCH 1/2] separate bootstrap code to get commandline, move it into
> > > [PATCH 2/2] add a header to create flexible bootstrap code
> > >
> > >
> >
> > I need to look more carefully at the details and your use case, but my
> > first impression is that at least patch 2 is not very beautiful due to
> > that large template header. Could you explain again why explicitly
> > calling the bootstrap code in a library is not sufficient?
>
> Just so that we are on the same page, the bootstrap code thats generated
> looks like this (in a couple variants):
> ----------------
> #include <xenomai/init.h>
>
> static int early_argc;
> static char *const *early_argv;
>
> int xenomai_bootstrap_getargv(int *argc, char *const** argv) { if
> (early_argc) { *argc = early_argc; *argv = early_argv; return 1; } return 0; }
>
> __bootstrap_ctor static void xenomai_bootstrap(void) { char *const *argv;
> int argc; if (xenomai_init_fetchargv(&argc, &argv) != 0) return;
> xenomai_init(&argc, &argv); early_argc = argc; early_argv = argv; }
> ----------------------
>
> I believe what you meant with bootstrap code is called with 'xenomai_init',
> and I dont plan to touch or replace that.
>
> The code further replicates the code from lib/boilerplate/init/bootstrap.c,
> with the important difference, that you can chose not to define a main
> function and assorted wrappers (one of my main motivations is to
> disable/separate that).
>
> >
> > Also note that this pattern may make it harder to maintain a
> > compatible interface along updates, increasing the risk of having to
> > recompile your application, rather than just replacing some central library,
> when Xenomai changes.
>
> before Patch #2:
> your-app --links-> lib/xenomai/bootstrap.o --calls->xenomai_init
>
> after Patch #2 (and an optional variant):
> your-app --contains-> include/xenomai/bootstrap-template.h
> --calls->xenomai_init
>
> this means I need no precompiled object 'lib/xenomai/bootstrap.o', and the
> ABI to the libs has not changed.
>
> You call a large header with functions not beautiful, I would call precompiled
> objects and the linker wrapping not beautiful.
> If we are pragmatic, with Patch #2 you can pick between 2 not beautiful
> solutions =)
>
> Patch #1 is the one changing the ABI in a not BW-compatible manner (adds
> one function), but Patch #2 arguably improves on that, as the .o objects from
> a compiler have no ABI stability guarantee whatsoever.
>
> Further I can freely use no-pic/pic/pie and other ABI-changing settings, as
> there is no need to link a object with potentially incompatible ABI
> (compiler,-
> version or settings).
>
> Norbert
________________________________
This message and any attachments are solely for the use of the intended
recipients. They may contain privileged and/or confidential information or
other information protected from disclosure. If you are not an intended
recipient, you are hereby notified that you received this email in error and
that any review, dissemination, distribution or copying of this email and any
attachment is strictly prohibited. If you have received this email in error,
please contact the sender and delete the message and any attachment from your
system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
