Date: Tue, 9 Aug 2016 08:12:51 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Christian Mauderer <christian.mauderer@embedded-brains.de>, Kristof Provost <kp@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Changes to pfctl to allow easier integration into a library Message-ID: <57A97463.9000801@embedded-brains.de> In-Reply-To: <4571f890-6d35-b843-9bd8-86966fe515f5@embedded-brains.de> References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> <cb7c6bb6-8160-3524-5432-d4ff46e16af5@embedded-brains.de> <0C7EC45D-C3BC-4417-AF77-3ACC027D28B5@FreeBSD.org> <a2479a3c-031c-c137-78a9-8a8f34a12100@embedded-brains.de> <B5DEAF43-9CBD-4C74-AE71-8B7FD278BAA8@FreeBSD.org> <336150f6-9dcd-873f-1f8f-a264dfa4c4ed@embedded-brains.de> <4571f890-6d35-b843-9bd8-86966fe515f5@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/08/16 16:54, Christian Mauderer wrote: > Am 02.08.2016 um 07:36 schrieb Christian Mauderer: >> >> Am 01.08.2016 um 20:36 schrieb Kristof Provost: >>> On 1 Aug 2016, at 16:32, Christian Mauderer wrote: >>> >>> Am 01.08.2016 um 16:02 schrieb Kristof Provost: >>> >>> On 1 Aug 2016, at 15:03, Christian Mauderer wrote: >>> >>> Can I improve anything to make the patches more acceptab= le? >>> >>> Can you explain why >>> 0003-pfctl-Pull-static-variables-out-of-the-function.patch i= s >>> required? >>> I=E2=80=99m not sure I see why you need it. >>> >>> I use roughly the following method for the global variables: >>> - I put all initialized (zero or value) variables into a special= named >>> linker section. >>> - In a wrapper around main() I do the following: >>> o First save the content of the section to a temporary memory sp= ace >>> o Execute the original (mostly unchanged) main() >>> o After main() finishes, I restore the content of the section >>> To simplify a later update to a newer source version, the differ= ence >>> between the sources we use and the original FreeBSD sources shou= ld be >>> minimal. Therefore my attempt to put the variables into a sectio= n is >>> the >>> following: >>> I create a header file (i.e. pfctl-data.h) that contains a match= ing >>> declaration of the global variables but with an added gcc attrib= ute >>> __attribute__((__section__("my_section_name"))). This header fil= e is >>> included at the end of the original pfctl.c. >>> >>> Oh. >>> Ick. >>> Clever, but =E2=80=A6 ick. >>> >>> I=E2=80=99m not a big fan of this patch, because it makes the code a = bit harder >>> to follow, rather than improving things as most of your other patches= do. >>> I suspect that something similar can be accomplished with a bit of >>> linker trickery. >>> >>> A first idea is to insert two new symbols (e.g. pf_begin/pf_end) in t= wo >>> separate files, the first before all of the pfctl object files, the >>> second after them. >>> This should let you group the .data section of the pfctl globals, >>> accomplishing what you do here with the *attribute* attribute. >>> >>> Regards, >>> Kristof >>> >> Hello Kristof, >> >> I agree that my solution is not optimal and that this specific patch >> does not really improve the code for you. So I'll try to find alternat= ives. >> >> The method you suggested would not work for us. We are using part of t= he >> FreeBSD sources as a library that is statically linked with the rest o= f >> the system. Using our build process, the order of the object files doe= s >> not guarantee an order of the symbols. As far as I know a fixed order >> can only be achieved by the section names. >> >> Theoretically it could be possible to get a similar result with some >> object file manipulation (renaming sections, ...). I'll check if I'm >> able to use such a solution instead and report back as soon as I can >> tell you more. >> >> Kind regards, >> >> Christian Mauderer >> > Hello Kristof, > > just the promised report: I'm quite convinced that a solution using > object file manipulation is possible. It only needs some additional wor= k > (some adaption to our build system) and therefore needs some time. But > we work toward it. So just ignore the patch 0003. I think on PowerPC the object file manipulations could turn out to be=20 rather difficult, since we would have to change also the relocation=20 types. On PowerPC we use the small-data area, so if you have in your=20 source code a global variable like int g; then the compiler generates small-data area relocations. However, if you = use int g __attribute__((__section__("x"))); then the compiler generates normal relocations. If you simply rename the=20 sections in an object file, e.g. from ".sdata" to ".x", then the=20 relocations cannot be resolved or are invalid at run-time. I think we=20 have to add the section attribute to all global variable declarations at=20 least in the RTEMS port of the FreeBSD code. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57A97463.9000801>