public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matthias Maennich <maennich@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags
Date: Mon, 25 Nov 2019 10:45:58 +0100	[thread overview]
Message-ID: <20191125094557.GA31961@linux-8ccs> (raw)
In-Reply-To: <b280c412-432b-ff54-acbd-a6bcc74b6e72@rasmusvillemoes.dk>

+++ Rasmus Villemoes [25/11/19 10:29 +0100]:
>cc += binutils ML
>
>[on @progbits v %progbits in generic (data only) assembly code]
>
>On 22/11/2019 12.44, Masahiro Yamada wrote:
>> On Fri, Nov 22, 2019 at 1:09 AM Jessica Yu <jeyu@kernel.org> wrote:
>>>
>
>>> I think this would work, and it feels like the more correct solution
>>> especially if arm isn't the only one with the odd progbits char. It
>>> might be overkill if it's just arm that's affected though. I leave it
>>> to Masahiro to see what he prefers.
>>>
>>
>>
>> BTW, is there any reason why
>> not use %progbits all the time?
>>
>>
>> include/linux/init.h hard-codes %progbits
>>
>>    #define __INITDATA .section ".init.data","aw",%progbits
>>    #define __INITRODATA .section ".init.rodata","a",%progbits
>>
>>
>> So, my understanding is '%' works for all architectures,
>> but it is better to ask 0-day bot to test it.
>
>It seems that you're absolutely right. The binutils source has code like
>
>+             if (*input_line_pointer == '@' || *input_line_pointer == '%')
>+               {
>+                 ++input_line_pointer;
>+                 if (strncmp (input_line_pointer, "progbits",
>+                              sizeof "progbits" - 1) == 0)
>+                   {
>+                     type = SHT_PROGBITS;
>+                     input_line_pointer += sizeof "progbits" - 1;
>+                   }
>+                 else if (strncmp (input_line_pointer, "nobits",
>+                                   sizeof "nobits" - 1) == 0)
>+                   {
>+                     type = SHT_NOBITS;
>+                     input_line_pointer += sizeof "nobits" - 1;
>+                   }

Yeah, I saw this too while digging. I also came across this commit in
the binutils source:

commit ecc054c097e7ced281d02ef9632eb0261a410b96
Author: Thomas Preud'homme <thomas.preudhomme@arm.com>
Date:   Fri Mar 2 11:51:34 2018 +0000

    [GDB/testsuite] Use %progbits in watch-loc.c

    While using @progbits in .pushsection work on some targets, it does not
    work on arm target where this introduces a comment. This patch replaces
    its use in gdb.dlang/watch-loc.c and gdb.mi/dw2-ref-missing-frame-func.c
    by %progbits which should work on all targets since it is used in
    target-independent elf/section7.s GAS test.

    2018-03-02  Thomas Preud'homme  <thomas.preudhomme@arm.com>

    gdb/testsuite/
            * gdb.dlang/watch-loc.c: Use %progbits instead of @progbits.
            * gdb.mi/dw2-ref-missing-frame-func.c: Likewise.

So that seems to confirm this theory :-) I'm just surprised it isn't
documented anywhere it seems.

>The only reason I thought one needed to do it differently on ARM is this
>from the gas docs:
>
>===
>   The optional TYPE argument may contain one of the following
>constants:
>
>'@progbits'
>     section contains data
>...
>   Note on targets where the '@' character is the start of a comment (eg
>ARM) then another character is used instead.  For example the ARM port
>uses the '%' character.
>===
>
>That doesn't suggest the possibility that % or some other character
>might work on all architectures.
>
>Jessica, can you resend using just %progbits to let kbuild chew on that?
>Please include a comment about the misleading gas documentation.

Yup, sounds good. Thanks!

Jessica

  reply	other threads:[~2019-11-25  9:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20 14:51 [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags Jessica Yu
2019-11-20 15:02 ` Jessica Yu
2019-11-21 10:51 ` Rasmus Villemoes
2019-11-21 16:09   ` Jessica Yu
2019-11-21 16:53     ` Will Deacon
2019-11-22 11:44     ` Masahiro Yamada
2019-11-25  9:29       ` Rasmus Villemoes
2019-11-25  9:45         ` Jessica Yu [this message]
2019-11-25 15:42 ` [PATCH v2] " Jessica Yu
2019-11-26  8:32   ` Masahiro Yamada
2019-11-26  9:55     ` Jessica Yu
2019-11-26 13:56     ` Matthias Maennich
2019-11-26 15:31       ` Jessica Yu
2019-11-26 16:02         ` Matthias Maennich
2019-11-26 16:12         ` Masahiro Yamada
2019-11-26 16:48           ` Jessica Yu
2019-12-05 16:42             ` Matthias Maennich
2019-12-06 12:41   ` [PATCH v3] " Jessica Yu
2019-12-12  6:22     ` Masahiro Yamada
2019-12-12 10:36       ` Jessica Yu
2019-12-12 14:16     ` [PATCH v4] " Jessica Yu
2019-12-12 14:29       ` Matthias Maennich
2019-12-16  9:41         ` Jessica Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191125094557.GA31961@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=arnd@arndb.de \
    --cc=binutils@sourceware.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=maennich@google.com \
    --cc=will@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox