From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 7 08:35:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 837F31065672; Wed, 7 Jul 2010 08:35:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 093A98FC22; Wed, 7 Jul 2010 08:35:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA20925; Wed, 07 Jul 2010 11:35:55 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OWQ6k-0000Iq-JD; Wed, 07 Jul 2010 11:35:54 +0300 Message-ID: <4C343C68.8010302@freebsd.org> Date: Wed, 07 Jul 2010 11:35:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> In-Reply-To: <4C321409.2070500@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 08:35:59 -0000 What do you think about something like the following? diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 1ee7717..ddfdefc 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -53,14 +53,17 @@ extern uintptr_t *__start_set_pcpu; extern uintptr_t *__stop_set_pcpu; -__asm__( -#ifdef __arm__ - ".section set_pcpu, \"aw\", %progbits\n" +#if defined(__arm__) +#define _PROGBITS "%progbits" #else - ".section set_pcpu, \"aw\", @progbits\n" +#define _PROGBITS "@progbits" #endif - "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" - "\t.previous"); +#define _CUSTOM_SECTION(name, flags, align) \ + __asm__( \ + ".section " __XSTRING(name) \ + ",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \ + "\t.p2align " __XSTRING(align) "\n" \ + "\t.previous") /* * Array of dynamic pcpu base offsets. Indexed by id. @@ -82,7 +85,10 @@ extern uintptr_t dpcpu_off[]; */ #define DPCPU_NAME(n) pcpu_entry_##n #define DPCPU_DECLARE(t, n) extern t DPCPU_NAME(n) -#define DPCPU_DEFINE(t, n) t DPCPU_NAME(n) __section("set_pcpu") __used + +#define DPCPU_DEFINE(t, n) \ + _CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT); \ + t DPCPU_NAME(n) __section("set_pcpu") __used /* * Accessors with a given base. The diff looks a little bit messier than the resulting macros :-) So I am pasting them too, just for your convenience: #if defined(__arm__) #define _PROGBITS "%progbits" #else #define _PROGBITS "@progbits" #endif #define _CUSTOM_SECTION(name, flags, align) \ __asm__( \ ".section " __XSTRING(name) \ ",\"" __XSTRING(flags) "\"," _PROGBITS "\n" \ "\t.p2align " __XSTRING(align) "\n" \ "\t.previous") ... #define DPCPU_DEFINE(t, n) \ _CUSTOM_SECTION(set_pcpu, aw, CACHE_LINE_SHIFT); \ t DPCPU_NAME(n) __section("set_pcpu") __used Not sure if _CUSTOM_SECTION is an overkill here or a useful/reusable thing. The idea is to tie '.section' directive to DPCPU_DEFINE macro, so that [empty] set_pcpu section is not created by merely including pcpu.h. Multiple DPCPU_DEFINE instances would cause multiple '.section' directives for set_pcpu, but that doesn't cause any problem. Here's an example of how this case looks in gcc-generated assembly (with two DPCPU_DEFINE instances): #APP .section set_pcpu,"aw",@progbits .p2align 7 .previous .section set_pcpu,"aw",@progbits .p2align 7 .previous ... #NO_APP ... .globl pcpu_entry_dpcpu_nvram1 .section set_pcpu,"aw",@progbits .align 8 .type pcpu_entry_dpcpu_nvram1, @object .size pcpu_entry_dpcpu_nvram1, 8 pcpu_entry_dpcpu_nvram1: .zero 8 .globl pcpu_entry_dpcpu_nvram2 .align 8 .type pcpu_entry_dpcpu_nvram2, @object .size pcpu_entry_dpcpu_nvram2, 8 pcpu_entry_dpcpu_nvram2: .zero 8 .data ... Here's objdump of the resulting module: objdump -x -w nvram.ko | fgrep set_pcpu 5 set_pcpu 00000010 0000000000000000 0000000000000000 00000380 2**7 CONTENTS, ALLOC, LOAD, DATA 0000000000000000 l O set_pcpu 0000000000000008 pcpu_entry_dpcpu_nvram1 0000000000000008 l O set_pcpu 0000000000000008 pcpu_entry_dpcpu_nvram2 0000000000000000 l d set_pcpu 0000000000000000 Looks good to me. -- Andriy Gapon