Re: Write test case for libstdc++ with C source
On 04/27/2014 03:01 PM, Sebastian Huber wrote: Hallo, I would like to add a test case to the libstdc++ tests to test for C/C++ compatibility of the atomic operations. A straight forward approach like in the attached patch doesn't work since the "dg-additional-sources" is not supported: ERROR: 29_atomics/atomic/pr60932-c++.cc: unknown dg option: dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3 "pr60932-c.c" " UNRESOLVED: 29_atomics/atomic/pr60932-c++.cc: unknown dg option: dg-additional-sources 3 pr60932-c.c for " dg-additional-sources 3 "pr60932-c.c" " Since I am not an expert in the GCC test suite scripts, is it possible to add such a test case at all with a moderate amount of work? Since this patch 2014-05-20 Sebastian Huber * testsuite/lib/libstdc++.exp (load_gcc_lib): Register loaded libs. I am one step further. The dg-additional-sources is recognized in the attached test case, but it seems to have no effect: Executing on host: /home/sh/git-build/b-gcc-devel-linux/./gcc/xg++ -shared-libgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc -nostdinc++ -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/sys-include -B/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/sh/archive/gcc-devel/libstdc++-v3/libsupc++ -I/home/sh/archive/gcc-devel/libstdc++-v3/include/backward -I/home/sh/archive/gcc-devel/libstdc++-v3/testsuite/util /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc -std=c++11 ./libtestc++.a -Wl,--gc-sections -lm -o ./pr60932-c++.exe(timeout = 600) spawn /home/sh/git-build/b-gcc-devel-linux/./gcc/xg++ -shared-libgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc -nostdinc++ -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/sys-include -B/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/sh/git-build/b-gcc-devel-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/sh/archive/gcc-devel/libstdc++-v3/libsupc++ -I/home/sh/archive/gcc-devel/libstdc++-v3/include/backward -I/home/sh/archive/gcc-devel/libstdc++-v3/testsuite/util /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc -std=c++11 ./libtestc++.a -Wl,--gc-sections -lm -o ./pr60932-c++.exe /tmp/ccN0vuIk.o: In function `main': /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /tmp/ccN0vuIk.o: In function `main': /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status FAIL: 29_atomics/atomic/pr60932-c++.cc (test for excess errors) Excess errors: /home/sh/archive/gcc-devel/libstdc++-v3/testsuite/29_atomics/atomic/pr60932-c++.cc:12: undefined reference to `i' collect2: error: ld returned 1 exit status extra_tool_flags are: -x c -std=c11 compiling and executing as C, not C++ Executing on host: /home/sh/git-build/b-gcc-devel-linux/./gcc/xgcc -B/home/sh/git-build/b-gcc-devel-linux/./gcc/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/bin/ -B/scratch/install-gcc-devel/x86_64-unknown-linux-gnu/lib/ -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/include -isystem /scratch/install-gcc-devel/x86_64-unknown-linux-gnu/sys-include -B/home/sh/git-build/b-gcc-devel-linux/x86_64-unkno
RFH: DWARF representation of mixed-mode registers
Sorry for the gdb/gcc crosspost, but can anyone offer any advice for
the situation Matthew describes in the message quoted below? We have
three ABIs:
(1) traditional o32 with 32-bit FP registers. The FP registers act as pairs
when storing doubles. Some architectures can only store one single-
precision value per pair while others can store one per register.
(2) o32 with 64-bit FP registers. Each FP register can store a single-
or double-precision value. Only even registers are call-saved,
meaning that the total FP save size is the same as for (1).
(3) o32 with indeterminate FP register width ("fpcc"). This is designed to
be individually link-compatible with (1) or (2) (but not both together,
which would be impossible). Among other things, doubles are restricted
to even registers and single-precision values can only be stored in
odd registers if they are treated as both call-clobbered and call-saved.
(1) is historical and shouldn't change. (2) and (3) are new ABIs that
are in the late stages of being defined.
The question is: what would be the best way of representing FP registers
in the DWARF information for (2) and (3), given that (1) and (3) and
(2) and (3) could be linked together?
Thanks,
Richard
Matthew Fortune writes:
> Hi Richard,
>
> I've been working through the debug issues for O32 FPXX and O32 FP64 and have
> identified some things to resolve along with proposed fixes...
>
> What to do with debug info for double precision registers and the O32 FPXX
> ABI? The choices are:
> 1) Do what O32 FP32 does and represent 8 byte values in two DW_OP_pieces
>referring to the relevant registers.
> 2) Do what O32 FP64 does and represent 8 byte values in a single register
> 3) Do a hybrid where 8-byte values sit in a single DW_OP_pieces.
>
> I'm tentatively swayed to (3) as it is a slightly unusual construct that means
> we should have better scope to detect it and do special handling. I've
> implemented that in the patch below but am still not sure. My next choice is
> (1)
> as it means there would only be special handling when debugging an O32 FP64
> program with FPXX modules rather than both O32 FP32 and O32 FP64.
>
> How to ensure unwinding will work when passing through functions with
> differing
> ABI variants? There isn't much room for debate here as we simply have to
> continue using the unwind table format as used in O32 FP32. This represents
> 32 32-bit floating point registers. A description of how O32 FP64 is modified
> to
> cope with this is on the O32 FR wiki page:
>
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#8._Re-definition_of_the_-mabi.3D32_-mfp64_ABI
>
> Copied here for archive
> ===
> Changes to O32 FP64:
>
> * 6 double-precision callee-save registers ($f20 to $f30 evens). This used to
> be
> 12 double-precision registers.
> * GNU ABI extensions for returning _Complex float and _Complex double are
> redefined to return the two components in $f0 and $f2 instead of $f0 and
> $f1.
> * The size of registers 32->63, which represent floating-point registers, in
> dwarf unwinding tables is set to 4-byte instead of the more natural choice
> of
> 8-byte. This is required to ensure all ABI variants which can interlink
> have a
> consistent view of unwind information. Unwind registers 32-63 are
> conceptually
> defined to represent the low and high 32-bits of a double precision value in
> even numbered registers. Register 32 is lo32($f0) and register 33 is
> hi32($f0).
> The odd-numbered 64-bit floating point registers for O32 FP64 are not
> represented in frame unwind information, this is OK because none of them are
> callee-saved. When saving or restoring a 64-bit callee-saved register two
> CFI
> directives must be emitted, one to represent the mapping for the lo32 frame
> register and one for the hi32 frame register.
> ===
>
> I have modified the --with-fp option to be --with-fp-32 where the -32
> corresponds
> to the -32 found in --with-arch-32 option. This is to support building a
> simple
> toolchain with one 64-bit ABI and one 32-bit ABI where the FP ABI for the
> 32-bit
> ABI can be set without affecting the 64-bit ABI.
>
> --with-arch-64=mips3 --with-arch-32=mips2 --with-fp-32=xx
>
> "gcc -mabi=64" then implies "-mips3 -mgp64 -mfp64"
> "gcc" then implies "-mips2 -mgp32 -mfpxx"
>
> Finally I have had to add ASM_SPECs to pass through -mhard-float,
> -msoft-float,
> -mdouble-float, -msingle-float. Without these building ASM sources for
> soft-float
> or single-float get marked as if they were hard-float double-precision with
> the
> new binutils .MIPS.abiflags support. This does of course mean that using an
> old
> GCC with a new binutils will lead to problems building soft-float or
> single-precision code.
>
> Attached is a patch that just addresses these issues rather than the whole
> FPXX
> patch again. I'll merge everything together and post the whole lot when things
