[PATCH v1 3/3] riscv/purgatory: do not link with string.o

[Petr Tesařík]

On Wed, 26 Jul 2023 03:36:39 +0800
kernel test robot <lkp at intel.com> wrote:

> Hi Petr,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on kees/for-next/pstore]
> [also build test ERROR on kees/for-next/kspp linus/master v6.5-rc3 next-20230725]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Petr-Tesarik/riscv-kexec-handle-R_RISCV_CALL_PLT-relocation-type/20230725-165116
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore
> patch link:    https://lore.kernel.org/r/a083f38c7c3acd6ac9542228e36947be30b58188.1690274483.git.petr.tesarik.ext%40huawei.com
> patch subject: [PATCH v1 3/3] riscv/purgatory: do not link with string.o
> config: riscv-randconfig-r001-20230725 (https://download.01.org/0day-ci/archive/20230726/202307260325.E3Uh9dYf-lkp@intel.com/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
> reproduce: (https://download.01.org/0day-ci/archive/20230726/202307260325.E3Uh9dYf-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202307260325.E3Uh9dYf-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
> >> ld.lld: error: undefined symbol: memcmp  
>    >>> referenced by ctype.c
>    >>>               arch/riscv/purgatory/purgatory.ro:(purgatory)  

Ah, I see... In my build, it was inlined by gcc (GCC-13), but I cannot
rely on that. Too bad...

OTOH I don't think it's worth implementing full support for GOT,
especially for functions that are not needed. I would rather either
write a RISC-V implementation of memcmp(), or split memcmp() from
lib/string.c.

Stay tuned for v2.

Petr T