From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Lobakin <alobakin@dlink.ru>,
Paul Burton <paulburton@kernel.org>,
clang-built-linux@googlegroups.com
Subject: Re: [PATCH] MIPS: mark some functions as weak to avoid conflict with Octeon ones
Date: Wed, 25 Mar 2020 02:46:47 +0000 (GMT) [thread overview]
Message-ID: <alpine.LFD.2.21.2003250240110.2689954@eddie.linux-mips.org> (raw)
In-Reply-To: <20200324164005.8259-1-masahiroy@kernel.org>
On Wed, 25 Mar 2020, Masahiro Yamada wrote:
> MIPS provides multiple definitions for the following functions:
>
> fw_init_cmdline
> __delay
> __udelay
> __ndelay
> memmove
> __rmemcpy
> memcpy
> __copy_user
>
> The generic ones are defined in lib-y objects, which are overridden by
> the Octeon ones when CONFIG_CAVIUM_OCTEON_SOC is enabled.
>
> The use of EXPORT_SYMBOL in static libraries potentially causes a
> problem for the llvm linker [1]. So, I want to forcibly link lib-y
> objects to vmlinux when CONFIG_MODULES=y.
>
> As a groundwork, we must fix multiple definitions that have been
> hidden by lib-y.
IIUC that causes known dead code to be included in the kernel image.
Wouldn't it be possible to actually omit replaced functions from output by
keying the build of the sources providing generic code with appropriate
CONFIG_* settings (such as CONFIG_GENERIC_DELAY, CONFIG_GENERIC_MEMCPY,
etc. or suchlike)?
Maciej
next prev parent reply other threads:[~2020-03-25 2:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 16:40 [PATCH] MIPS: mark some functions as weak to avoid conflict with Octeon ones Masahiro Yamada
2020-03-24 19:59 ` Nick Desaulniers
2020-03-25 2:46 ` Maciej W. Rozycki [this message]
2020-03-25 7:33 ` 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=alpine.LFD.2.21.2003250240110.2689954@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=alobakin@dlink.ru \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=paulburton@kernel.org \
--cc=tsbogend@alpha.franken.de \
/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;
as well as URLs for NNTP newsgroup(s).