On Wed, Mar 13, 2024 at 3:23 PM HAGIO KAZUHITO(萩尾 一仁) <[email protected]>
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.)
>

For these two patches: Ack.

Thanks
Lianbo


> Ming, Lianbo, could you check these?
>
> Thanks,
> Kazu
>
>
> >
> > Reported-by: Xiujie Jiang <[email protected]>
> > Signed-off-by: Ming Wang <[email protected]>
> > ---
> >   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 -- [email protected]
To unsubscribe send an email to [email protected]
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki

Reply via email to