Re: Trying to track down problem with packed.com from testsuite

[Gaius Mulley]

john o goyo <jog37@riddermarkfarm.ca> writes:

> Greetings, Gaius.
>
> On 2024-08-30 06:26, Gaius Mulley wrote (in part):
> [...]
>>
>> Hi John,
>>
>> Does the following work on Solaris with gdb, it will invoke cc1gm2
>> with all default options and the source file hello.mod.
>>
>>
>> $ gm2 hello.mod -wrapper gdb,--args
>>
>> GNU gdb (Debian 13.1-3) 13.1
>> Copyright (C) 2023 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <https://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>      <http://www.gnu.org/software/gdb/documentation/>.
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from 
>> /home/gaius/opt/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/cc1gm2...
>> (gdb) break gimplify_function_tree(tree_node*)
>> Breakpoint 1 at 0xe52080: file ../../gcc/tree.h, line 3632.
>> (gdb) run
>> Starting program:
>> /home/gaius/opt/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/cc1gm2
>> -imultiarch x86_64-linux-gnu -quiet -dumpdir a- -dumpbase hello.mod
>> -dumpbase-ext .mod -mtune=generic -march=x86-64 -g -fm2-pathname=-
>> -fm2-pathnameI. -fgen-module-list=- -fscaffold-dynamic
>> -fscaffold-main -flibs=m2cor,m2log,m2pim,m2iso -fm2-pathname=-
>> -fm2-pathnameI. hello.mod -o /tmp/ccQdbK7K.s
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>
>> Breakpoint 1, gimplify_function_tree (fndecl=0x7ffff76cc300) at 
>> ../../gcc/tree.h:3632
>> 3632   if (TREE_CODE (__t) != __c)
>> (gdb)
>>
>
> Yes, the above does indeed work but I am still in the dark.  Please
> remember that I am woefully ignorant of the inner workings of gcc.
>
> Here is what I tried:
>
> [~/opt/gm2/testsuite]=> gm2-14 packed.mod -fiso -O2 -wrapper gdb,--args
> GNU gdb (GDB) 15.1
> [...]
> This GDB was configured as "sparcv9-sun-solaris2.11".
> [...]
> Reading symbols from
> /home/build/gcc/14.2.0/libexec/gcc/sparc-sun-solaris2.11/14.2.0/cc1gm2...
> [...]
> (gdb) break gimplify_function_tree(tree_node*)
> Breakpoint 1 at 0x8a6f40: file
> /home/build/opt/gcc/src/gcc-14.2.0/gcc/gimplify.cc, line 19333.
> (gdb) r
> Starting program:
> /home/build/gcc/14.2.0/libexec/gcc/sparc-sun-solaris2.11/14.2.0/cc1gm2
> -quiet -dumpdir a- -dumpbase packed.mod -dumpbase-ext .mod -mcpu=v9
> -O2 -fiso -fm2-pathname=- -fm2-pathnameI. -fgen-module-list=-
> -fscaffold-dynamic -fscaffold-main -flibs=m2iso,m2cor,m2pim,m2log
> -fm2-pathname=- -fm2-pathnameI. packed.mod -o /var/tmp//ccb3aGgQ.s
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
> [Switching to Thread 1 (LWP 1)]
>
> Thread 2 hit Breakpoint 1, gimplify_function_tree (fndecl=0xfb474700)
>     at /home/build/opt/gcc/src/gcc-14.2.0/gcc/gimplify.cc:19333
> 19333   {
> (gdb) l
> 19328      Return the sequence of GIMPLE statements corresponding to
> the body
> 19329      of FNDECL.  */
> 19330
> 19331   void
> 19332   gimplify_function_tree (tree fndecl)
> 19333   {
> 19334     gimple_seq seq;
> 19335     gbind *bind;
> 19336
> 19337     gcc_assert (!gimple_body (fndecl));
> [...]

I wonder what the output from the tree dump would be at this point?

(gdb) print debug_tree (fndecl)

or perhaps 'pf' might be able to get a m2 description of the tree:

(gdb) print pf (fndecl)

> (gdb) del 1
> (gdb) c
> Continuing.
>
> Thread 2 received signal SIGSEGV, Segmentation fault.
> build_call_expr (fndecl=0x0, n=1) at

at this point it going to fail with fndecl = 0x0.


I prefer to debug without optimization - but obviously if it fails with
-O2 or greater then this doesn't apply.  For my clarity is it that gm2
-O2 fails or is it that the build process using -O2 fails.  If it is gm2
-O2 then it would be worth building gcc/gm2 with full debugging (as the
-O2 throws away too much useful info).

Here is my debug build script which might be adapted (it generates all
.o files without optimization and will enable gdb debugging):

#!/bin/bash

if [ -d $HOME/GCC/gcc-read-write ] ; then
    cd $HOME/GCC/gcc-read-write
    ./contrib/download_prerequisites
    echo "about to remove all files under" `pwd`/build
    echo "press enter to continue"
    read ans
    rm -rf build
    mkdir build
    cd build
    CFLAGS=-g CXXFLAGS=-g ../configure --prefix=$HOME/opt --disable-bootstrap 
--with-build-config="bootstrap-debug" --enable-languages=m2 && make -j 30 > 
$HOME/log 2> $HOME/err
fi

does this help?

regards,
Gaius


> /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree.cc:10913
> 10913     return build_call_expr_loc_array (UNKNOWN_LOCATION, fndecl,
> n, argarray);
>
> [set breakpoint at l10913 and reran]
> Thread 2 hit Breakpoint 2, build_call_expr_loc_array (loc=0,
> fndecl=0x0, n=1, argarray=0xffbfe850)
>     at /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree.cc:10863
> 10863     tree fntype = TREE_TYPE (fndecl);
> (gdb) bt
> #0  build_call_expr_loc_array (loc=0, fndecl=0x0, n=1, argarray=0xffbfe850)
>     at /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree.cc:10863
> #1  build_call_expr (fndecl=0x0, n=1) at
>  /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree.cc:10913
> #2  0x00d2ece8 in build_cltz_expr (src=0xfb481680, leading=<optimized
>  out>, define_at_zero=<optimized out>)
>     at /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree-ssa-loop-niter.cc:2290
> #3  0x00d3c5fc in number_of_iterations_cltz_complement
>  (exit=<optimized out>, loop=0xfb412f80,
>     code=<optimized out>, niter=0xffbfeb88) at
> /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree-ssa-loop-niter.cc:2542
> #4  number_of_iterations_bitcount (loop=0xfb412f80, exit=<optimized
>  out>, code=<optimized out>, niter=0xffbfeb88)
>     at /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree-ssa-loop-niter.cc:2628
> [...]
> (gdb) l
> 10858      ARGARRAY.  */
> 10859
> 10860   tree
> 10861   build_call_expr_loc_array (location_t loc, tree fndecl, int n,
> tree *argarray)
> 10862   {
> 10863     tree fntype = TREE_TYPE (fndecl);
> 10864     tree fn = build1 (ADDR_EXPR, build_pointer_type (fntype), fndecl);
> 10865
> 10866     return fold_build_call_array_loc (loc, TREE_TYPE (fntype),
> fn, n, argarray);
> 10867   }
> (gdb) n
>
> Thread 2 received signal SIGSEGV, Segmentation fault.
> build_call_expr (fndecl=0x0, n=1) at
> /home/build/opt/gcc/src/gcc-14.2.0/gcc/tree.cc:10913
> 10913     return build_call_expr_loc_array (UNKNOWN_LOCATION, fndecl,
> n, argarray);
>
> Does this offer you any clues on the problem or how to proceed?
>
> Sincerely,
> john