On 3/13/24 15:23, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2024/03/08 12:18, Ming Wang wrote:
>> The following link error exists when building with LOONGARCH64
>> machine:
>>
>> /usr/bin/ld: proc-service.o: in function `.LVL71':
>> proc-service.c:(.text+0x324): undefined reference to `fill_gregset ...
>> /usr/bin/ld: proc-service.o: in function `.LVL77':
>> proc-service.c:(.text+0x364): undefined reference to `supply_gregset ...
>> /usr/bin/ld: proc-service.o: in function `.LVL87':
>> proc-service.c:(.text+0x3c4): undefined reference to `fill_fpregset ...
>> /usr/bin/ld: proc-service.o: in function `.LVL93':
>> proc-service.c:(.text+0x404): undefined reference to `supply_fpregset
>> collect2: error: ld returned 1 exit status
>>
>> The cause of the error is that the definition of a function such as
>> fill_gregset is not implemented. This patch is used to fix this error.
>>
>> v1 -> v2:
>> Fix compilation errors.
> Thanks for the v2, the warnings are gone. but I found another problem..
>
> When we add a patch to gdb-10.2.patch, a LOONGARCH64 build will fail with
> the following redefinition errors. There is need to remove the gdb-10.2
> directory before rebuilding. It looks like it's because the patch command
> cannot detect previously applied patches for newly created loongarch files,
> and those files get duplicated code..
>
> $ git am /tmp/0001-LoongArch64-Fixed-link-errors-when-build-on-LOO.patch
> Applying: LoongArch64: Fixed link errors when build on LOONGARCH64 machine
> $ make -j 16 warn target=LOONGARCH64
> ...
> patching file gdb-10.2/bfd/configure.ac
> Reversed (or previously applied) patch detected! Skipping patch.
> 1 out of 1 hunk ignored
> patching file gdb-10.2/bfd/cpu-loongarch.c <<-- cannot detect previously applied patch
> patching file gdb-10.2/bfd/elf-bfd.h
> patching file gdb-10.2/bfd/elf.c
> ...
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -DBINDIR=\"/usr/local/bin\" -DLIBDIR=\"/usr/local/lib\" -I. -I. -I./../include -DHAVE_loongarch_elf64_vec -DHAVE_loongarch_elf32_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I./../zlib -g -O2 -MT elf-properties.lo -
> MD -MP -MF .deps/elf-properties.Tpo -c elf-properties.c -o elf-properties.o
> cpu-loongarch.c:86:33: error: redefinition of 'bfd_loongarch32_arch'
> static const bfd_arch_info_type bfd_loongarch32_arch =
> ^~~~~~~~~~~~~~~~~~~~
> ...
> make: *** [Makefile:254: all] Error 2
>
> $ grep BFD gdb-10.2/bfd/cpu-loongarch.c
> /* BFD support for LoongArch.
> This file is part of BFD, the Binary File Descriptor library.
> /* BFD support for LoongArch.
> This file is part of BFD, the Binary File Descriptor library.
>
>
> I found that it's due to not using '/dev/null' for the newly added files
> in gdb-10.2.patch. I'd like to fix this issue before applying this patch.
>
> I've attached two patches:
> - 1/2 fixes the issue above.
> - 2/2 is Ming's patch and I added "rm -f gdb-10.2/gdb/loongarch-linux-tdep.c"
> for the file modified multiple times (but not included in gdb-10.2.tar.gz.)
>
> Ming, Lianbo, could you check these?
Hi, Kazu
Thank you very much for the patch. Following your steps, I have the same errors here.
Before apply Kazu patch:
wangming@crazy:~/gerrit/crash_upstream$ git am 0001-LoongArch64-Fixed-link-errors-when-build-on-LOONGARC.patch
Applying: LoongArch64: Fixed link errors when build on LOONGARCH64 machine
wangming@crazy:~/gerrit/crash_upstream$ make -j 32 warn target=LOONGARCH64
There are some compilation errors,
---
cpu-loongarch.c:86:33: error: redefinition of ‘bfd_loongarch32_arch’
86 | static const bfd_arch_info_type bfd_loongarch32_arch =
| ^~~~~~~~~~~~~~~~~~~~
cpu-loongarch.c:25:33: note: previous definition of ‘bfd_loongarch32_arch’ with type ‘bfd_arch_info_type’ {aka ‘const struct bfd_arch_info’}
25 | static const bfd_arch_info_type bfd_loongarch32_arch =
| ^~~~~~~~~~~~~~~~~~~~
cpu-loongarch.c:104:26: error: redefinition of ‘bfd_loongarch_arch’
104 | const bfd_arch_info_type bfd_loongarch_arch =
| ^~~~~~~~~~~~~~~~~~
cpu-loongarch.c:43:26: note: previous definition of ‘bfd_loongarch_arch’ with type ‘bfd_arch_info_type’ {aka ‘const struct bfd_arch_info’}
43 | const bfd_arch_info_type bfd_loongarch_arch =
| ^~~~~~~~~~~~~~~~~~
make[7]: *** [Makefile:1611: cpu-loongarch.lo] Error 1
make[7]: *** Waiting for unfinished jobs....
elfxx-loongarch.c:1650:16: error: redefinition of ‘struct loongarch_reloc_howto_type_struct’
1650 | typedef struct loongarch_reloc_howto_type_struct
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
elfxx-loongarch.c:32:16: note: originally defined here
32 | typedef struct loongarch_reloc_howto_type_struct
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
elfxx-loongarch.c:1657:3: error: conflicting types for ‘loongarch_reloc_howto_type’; have ‘struct loongarch_reloc_howto_type_struct’
1657 | } loongarch_reloc_howto_type;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
---
After apply Kazu patch:
wangming@crazy:~/gerrit/crash_upstream$ git am Kazu_patch/*
Applying: gdb-10.2.patch: Fix duplicated code by re-applying patch
Applying: LoongArch64: Fixed link errors when build on LOONGARCH64 machine
wangming@crazy:~/gerrit/crash_upstream$ make -j 32 warn target=LOONGARCH64
No compilation errors,
---
CXX tui/tui-hooks.o
CXX tui/tui-source.o
CXX tui/tui-winsource.o
CXX valops.o
CXX value.o
GEN init.c
gcc -c -g -DLOONGARCH64 -DGDB_10_2 -g -O2 build_data.c -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector -Wformat-security
ar -rs crashlib.a main.o tools.o global_data.o memory.o filesys.o help.o task.o build_data.o kernel.o test.o gdb_interface.o net.o dev.o bpf.o printk.o alpha.o x86.o ppc.o ia64.o s390.o s390x.o s390dbf.o ppc64.o x86_64.o arm.o arm64.o mips.o mips64.o riscv64.o loongarch64.o sparc64.o extensions.o remote.o va_server.o va_server_v1.o symbols.o cmdline.o lkcd_common.o lkcd_v1.o lkcd_v2_v3.o lkcd_v5.o lkcd_v7.o lkcd_v8.o lkcd_fix_mem.o s390_dump.o netdump.o diskdump.o makedumpfile.o xendump.o lkcd_x86_trace.o unwind_v1.o unwind_v2.o unwind_v3.o unwind_x86_32_64.o unwind_arm.o xen_hyper.o xen_hyper_command.o xen_hyper_global_data.o xen_hyper_dump_tables.o kvmdump.o qemu.o qemu-load.o sadump.o ipcs.o ramdump.o vmware_vmss.o vmware_guestdump.o xen_dom0.o kaslr_helper.o sbitmap.o maple_tree.o
CXXLD gdb
---
I'm very sorry that I didn't find the issue introduced by my patch before.
Thanks,
Ming
>
> Thanks,
> Kazu
>
>
>> Reported-by: Xiujie Jiang <jiangxiujie@xxxxxxxxxx>
>> Signed-off-by: Ming Wang <wangming01@xxxxxxxxxxx>
>> ---
>> gdb-10.2.patch | 33 +++++++++++++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/gdb-10.2.patch b/gdb-10.2.patch
>> index a7018a2..5d34407 100644
>> --- a/gdb-10.2.patch
>> +++ b/gdb-10.2.patch
>> @@ -16057,3 +16057,36 @@ exit 0
>> m10200-dis.c
>> m10200-opc.c
>> m10300-dis.c
>> +--- gdb-10.2/gdb/loongarch-linux-tdep.c.orig
>> ++++ gdb-10.2/gdb/loongarch-linux-tdep.c
>> +@@ -707,3 +707,30 @@ _initialize_loongarch_linux_tdep ()
>> + gdbarch_register_osabi (bfd_arch_loongarch, bfd_mach_loongarch64,
>> + GDB_OSABI_LINUX, loongarch_linux_init_abi);
>> + }
>> ++
>> ++/* Wrapper functions. These are only used by libthread_db. */
>> ++#include <sys/procfs.h>
>> ++extern void supply_gregset (struct regcache *regcache,const prgregset_t *gregset);
>> ++extern void fill_gregset (const struct regcache *regcache, prgregset_t *gregset, int regno);
>> ++extern void supply_fpregset (struct regcache *regcache, const prfpregset_t *fpregset);
>> ++extern void fill_fpregset (const struct regcache *regcache, prfpregset_t *fpregset, int regno);
>> ++
>> ++void supply_gregset (struct regcache *regcache, const prgregset_t *gregset)
>> ++{
>> ++ loongarch_elf_gregset.supply_regset (NULL, regcache, -1, gregset, sizeof (prgregset_t));
>> ++}
>> ++
>> ++void fill_gregset (const struct regcache *regcache, prgregset_t *gregset, int regno)
>> ++{
>> ++ loongarch_elf_gregset.collect_regset (NULL, regcache, regno, gregset, sizeof (prgregset_t));
>> ++}
>> ++
>> ++void supply_fpregset (struct regcache *regcache, const prfpregset_t *fpregset)
>> ++{
>> ++ loongarch_elf_fpregset.supply_regset (NULL, regcache, -1, fpregset, sizeof (prfpregset_t));
>> ++}
>> ++
>> ++void fill_fpregset (const struct regcache *regcache, prfpregset_t *fpregset, int regno)
>> ++{
>> ++ loongarch_elf_fpregset.collect_regset (NULL, regcache, regno, fpregset, sizeof (prfpregset_t));
>> ++}
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
