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>