[Bug backtrace/27621] New: GDB has issue to show backtrace if the breakpoint is in a function with more then 8 parameters - only for target aarch64-elf ILP32

[Bug backtrace/27621] New: GDB has issue to show backtrace if the breakpoint is in a function with more then 8 parameters - only for target aarch64-elf ILP32

[filip.bascarevic at siemens dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27621

            Bug ID: 27621
           Summary: GDB has issue to show backtrace if the breakpoint is
                    in a function with more then 8 parameters - only for
                    target aarch64-elf ILP32
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: filip.bascarevic at siemens dot com
  Target Milestone: ---
              Host: x86_64-w64-mingw32
            Target: aarch64-elf ilp32

Created attachment 13323
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13323&action=edit
This is a small example that demonstrates the bug. Content is just start.c
start.S and start.lk and also scripts which will help you build the example.
This example doesn't contain any include.

Dear GDB team,

the Siemens developers noticed one issue in a GDB 10.1 and we don't know how to
deal with it. It occurs only for an aarch64 ilp32 target. Generally when we put
a breakpoint into function with more the 8 arguments then GDB has a problem
showing backtrace. To be exact, the last function is shown in an endless loop
unless GDB is forced to quit or the backtrace limit is set.  

I’ve created a small example to reproduce this problem with Qemu (4.1) and GCC
10.2 toolchain. Inside the package, there is a ‘readme.txt’ file with
instructions on how to build, start Qemu and GDB (with GDB commands) to
demonstrate the problem. The interesting fact is that if you use LP64 ABI than
this problem does not occur. I am informed that the GDB support for ilp32 has
never been committed but somehow it works in a version of GCC 8.1 and GDB 8.1

NOTES:
1. This example is compiled on Windows 10 using aarch64_elf compiler for
Windows. It contains only one simple .c and one .S file. To successfully
compile it please change a PATH of the toolchain and QEMU directory at the
beginning of the script build_and_run_qemu.cmd.
2. Also update a path of the GDB at the beginning of the run_gdb.cmd script.
3. As I mentioned above, we compiled that example with aarch64_elf compiler on
Windows 10. Because this ILP32 target is really specific, we built our
toolchain with MinGW using this command: 

$SRCDIR/configure --host=x86_64-w64-mingw32  --build=x86_64-w64-mingw32 
--prefix=$prefix --target=aarch64-elf --disable-nls --enable-multilib
--with-multilib-list=lp64,ilp32 --enable-languages=c,c++
--disable-decimal-float --with-sysroot=$prefix --without-headers
--disable-shared --disable-threads --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --disable-libstdcxx-pch
--disable-win32-registry '--with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-newlib --with-gcc --with-gnu-as
--with-gnu-ld --with-gmp=$prefixlocal --with-mpfr=$prefixlocal
--with-mpc=$prefixlocal --with-isl=$prefixlocal --with-zstd=$prefixlocal ||
return $ECONFIGURE

and GDB is built with this command:

$SRCDIR/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--prefix=$prefix --disable-nls --target=aarch64-elf --disable-shared
--with-python=/python/python.exe
'--with-gdb-datadir='\''${prefix}'\''/share/gdb' --with-expat
--with-libexpat-prefix=$prefixlocal

Please let me know if I can assist any further. In the attachment, you can find
an example that can help you with reproducing the issue. Also before a couple
of days, I posted this question to the GCC community and they thought this
issue is related to you.

With best regards,
MSc. Filip Bascarevic

Siemens, s.r.o.
ADV D EU CZ AE AC 4
Anglicke nabrezi 2434/1
301 00 Plzen, Czech Republic 
filip.bascarevic@siemens.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.