mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Palmer Dabbelt <palmer@rivosinc.com>, <masahiroy@kernel.org>
Cc: <mcgrof@kernel.org>, <nathan@kernel.org>,
	<ndesaulniers@google.com>, <nicolas@fjasle.eu>,
	<linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] modpost: move some defines to the file head
Date: Fri, 21 Jul 2023 17:11:15 +0800	[thread overview]
Message-ID: <df5a23f0-43cc-dd85-f47b-c068a7f2785f@huawei.com> (raw)
In-Reply-To: <mhng-7876bf10-0477-4ca6-af22-e3479e8ad123@palmer-ri-x1c9a>

Hi, kindly ping, the build issue still exist in Linux-next.

On 2023/7/13 0:28, Palmer Dabbelt wrote:
> On Wed, 12 Jul 2023 08:55:23 PDT (-0700), masahiroy@kernel.org wrote:
>> +To: Luis Chamberlain, the commiter of the breakage
>>
>>
>>
>> On Wed, Jul 12, 2023 at 10:44 AM Kefeng Wang 
>> <wangkefeng.wang@huawei.com> wrote:
>>>
>>> with "module: Ignore RISC-V mapping symbols too", build error occurs,
>>>
>>> scripts/mod/modpost.c: In function ‘is_valid_name’:
>>> scripts/mod/modpost.c:1055:57: error: ‘EM_RISCV’ undeclared (first 
>>> use in this function)
>>>   return !is_mapping_symbol(name, elf->hdr->e_machine == EM_RISCV);
>>>
>>> Fix it by moving the EM_RISCV to the file head, also some other
>>> defines in case of similar problem in the future.
>>
>>
>>
>> BTW, why is the flag 'is_riscv' needed?
>>
>>
>> All symbols starting with '$' look special to me.
>>
>>
>>
>> Why not like this?
>>
>>
>>        if (str[0] == '$')
>>                  return true;
>>
>>        return false;
> 
> There's a bit of commentary in the v1 
> <https://lore.kernel.org/all/20230707054007.32591-1-palmer@rivosinc.com/>, but essentially it's not necessary.  I just wanted to play things safe and avoid changing the mapping symbol detection elsewhere in order to deal with RISC-V.
> 
> IIRC we decided $ was special in RISC-V because there were some other 
> ports that behaved that way, but it wasn't universal.  If folks are OK 
> treating $-prefixed symbols as special everywhere that's fine with me, I 
> just wasn't sure what the right answer was.
> There's also some similar arch-specific-ness with the labels and such in 
> here.
> 
>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>> ---
>>>  scripts/mod/modpost.c | 32 ++++++++++++++++----------------
>>>  1 file changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>>> index 7c71429d6502..885cca272eb8 100644
>>> --- a/scripts/mod/modpost.c
>>> +++ b/scripts/mod/modpost.c
>>> @@ -60,6 +60,22 @@ static unsigned int nr_unresolved;
>>>
>>>  #define MODULE_NAME_LEN (64 - sizeof(Elf_Addr))
>>>
>>> +#ifndef EM_RISCV
>>> +#define EM_RISCV               243
>>> +#endif
>>> +
>>> +#ifndef R_RISCV_SUB32
>>> +#define R_RISCV_SUB32          39
>>> +#endif
>>> +
>>> +#ifndef EM_LOONGARCH
>>> +#define EM_LOONGARCH           258
>>> +#endif
>>> +
>>> +#ifndef R_LARCH_SUB32
>>> +#define R_LARCH_SUB32          55
>>> +#endif
>>> +
>>>  void __attribute__((format(printf, 2, 3)))
>>>  modpost_log(enum loglevel loglevel, const char *fmt, ...)
>>>  {
>>> @@ -1428,22 +1444,6 @@ static int addend_mips_rel(uint32_t *location, 
>>> Elf_Rela *r)
>>>         return 0;
>>>  }
>>>
>>> -#ifndef EM_RISCV
>>> -#define EM_RISCV               243
>>> -#endif
>>> -
>>> -#ifndef R_RISCV_SUB32
>>> -#define R_RISCV_SUB32          39
>>> -#endif
>>> -
>>> -#ifndef EM_LOONGARCH
>>> -#define EM_LOONGARCH           258
>>> -#endif
>>> -
>>> -#ifndef R_LARCH_SUB32
>>> -#define R_LARCH_SUB32          55
>>> -#endif
>>> -
>>>  static void section_rela(struct module *mod, struct elf_info *elf,
>>>                          Elf_Shdr *sechdr)
>>>  {
>>> -- 
>>> 2.41.0
>>>

  reply	other threads:[~2023-07-21  9:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12  1:57 Kefeng Wang
2023-07-12 15:55 ` Masahiro Yamada
2023-07-12 16:28   ` Palmer Dabbelt
2023-07-21  9:11     ` Kefeng Wang [this message]
2023-07-21 11:58     ` Masahiro Yamada
2023-07-21 14:01       ` Palmer Dabbelt
2023-07-21 14:19         ` Masahiro Yamada

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=df5a23f0-43cc-dd85-f47b-c068a7f2785f@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=palmer@rivosinc.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

all inboxes | Powered by JetHome®