From owner-freebsd-hackers@freebsd.org Tue Aug 9 06:12:57 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B74ABB3A11 for ; Tue, 9 Aug 2016 06:12:57 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 141F01303; Tue, 9 Aug 2016 06:12:56 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1bX0HV-0005w1-Tr; Tue, 09 Aug 2016 08:12:53 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bX0HV-0000WA-KX; Tue, 09 Aug 2016 08:12:53 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3B4072A1808; Tue, 9 Aug 2016 08:13:15 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gEi6MDmn8Rsk; Tue, 9 Aug 2016 08:13:14 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 9D2B12A1807; Tue, 9 Aug 2016 08:13:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oGTHZS-uhEOd; Tue, 9 Aug 2016 08:13:14 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 7F3302A000B; Tue, 9 Aug 2016 08:13:14 +0200 (CEST) Subject: Re: Changes to pfctl to allow easier integration into a library To: Christian Mauderer , Kristof Provost References: <25df9fd5-be75-b9ae-aa3a-22abef3bddf0@embedded-brains.de> <0C7EC45D-C3BC-4417-AF77-3ACC027D28B5@FreeBSD.org> <336150f6-9dcd-873f-1f8f-a264dfa4c4ed@embedded-brains.de> <4571f890-6d35-b843-9bd8-86966fe515f5@embedded-brains.de> Cc: "freebsd-hackers@freebsd.org" From: Sebastian Huber Message-ID: <57A97463.9000801@embedded-brains.de> Date: Tue, 9 Aug 2016 08:12:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4571f890-6d35-b843-9bd8-86966fe515f5@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/22054/Tue Aug 9 05:18:33 2016) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 06:12:57 -0000 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= .