| Message ID | 20250330034539.965018-1-thiago.bauermann@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | testsuite: fix is_aarch32_target | expand |
On 3/29/25 11:45 PM, Thiago Jung Bauermann wrote: > Commit > > c221b2f77080 Testsuite: Add gdb_can_simple_compile > > changed the source file name extension of the test program from .s to .c > resulting in compile fails. This, in turn, causes is_aarch32_target > checks to fail. > > Change the test source from an assembly program to a C program using > inline assembly. > > is_amd64_regs_target had a similar problem, which was fixed by commit > > 224d30d39365 testsuite: fix is_amd64_regs_target > > This fix — and commit message — are mostly copied from it. > --- > gdb/testsuite/lib/gdb.exp | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > I'm not actually affected by this bug, and just noticed it because of the > strange compilation error when building the aarch32.c test file: > > compiler exited with status 1 > output is: > /path/gdb/testsuite/temp/232375/aarch32.c:1:9: error: unknown type name 'mov' > 1 | mov r0, r0 > | ^~~ > /path/gdb/testsuite/temp/232375/aarch32.c:2:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mov' > 2 | mov r1, r1 > | ^~~ > > > It only affects aarch64 machines with the aarch64 "execution domain"¹ > (i.e., the default one) using a toolchain configured to produce 32-bit > binaries. Our aarch32 systems are containers using the linux32 command, so > GDB and DejaGNU see armv8l as the architecture/"execution domain" and > is_aarch32_target works correctly. > > ¹ See setarch(8) man page. > LGTM, thanks. Approved-By: Simon Marchi <simon.marchi@efficios.com> Simon
Simon Marchi <simark@simark.ca> writes: > On 3/29/25 11:45 PM, Thiago Jung Bauermann wrote: >> Commit >> >> c221b2f77080 Testsuite: Add gdb_can_simple_compile >> >> changed the source file name extension of the test program from .s to .c >> resulting in compile fails. This, in turn, causes is_aarch32_target >> checks to fail. >> >> Change the test source from an assembly program to a C program using >> inline assembly. >> >> is_amd64_regs_target had a similar problem, which was fixed by commit >> >> 224d30d39365 testsuite: fix is_amd64_regs_target >> >> This fix — and commit message — are mostly copied from it. >> --- >> gdb/testsuite/lib/gdb.exp | 15 +++++++++------ >> 1 file changed, 9 insertions(+), 6 deletions(-) >> >> I'm not actually affected by this bug, and just noticed it because of the >> strange compilation error when building the aarch32.c test file: >> >> compiler exited with status 1 >> output is: >> /path/gdb/testsuite/temp/232375/aarch32.c:1:9: error: unknown type name 'mov' >> 1 | mov r0, r0 >> | ^~~ >> /path/gdb/testsuite/temp/232375/aarch32.c:2:9: error: expected '=', ',', ';', 'asm' or >> '__attribute__' before 'mov' >> 2 | mov r1, r1 >> | ^~~ >> >> >> It only affects aarch64 machines with the aarch64 "execution domain"¹ >> (i.e., the default one) using a toolchain configured to produce 32-bit >> binaries. Our aarch32 systems are containers using the linux32 command, so >> GDB and DejaGNU see armv8l as the architecture/"execution domain" and >> is_aarch32_target works correctly. >> >> ¹ See setarch(8) man page. >> > > LGTM, thanks. > > Approved-By: Simon Marchi <simon.marchi@efficios.com> > > Simon Thanks! Pushed as commit 01e4635523d2.
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 761a4f117568..59967c70cda9 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -3937,13 +3937,16 @@ gdb_caching_proc is_aarch32_target {} { return 0 } - set list {} - foreach reg \ - {r0 r1 r2 r3} { - lappend list "\tmov $reg, $reg" - } + return [gdb_can_simple_compile aarch32 { + int main (void) { + asm ("\tmov r0, r0"); + asm ("\tmov r1, r1"); + asm ("\tmov r2, r2"); + asm ("\tmov r3, r3"); - return [gdb_can_simple_compile aarch32 [join $list \n]] + return 0; + } + }] } # Return 1 if this target is an aarch64, either lp64 or ilp32.
Commit c221b2f77080 Testsuite: Add gdb_can_simple_compile changed the source file name extension of the test program from .s to .c resulting in compile fails. This, in turn, causes is_aarch32_target checks to fail. Change the test source from an assembly program to a C program using inline assembly. is_amd64_regs_target had a similar problem, which was fixed by commit 224d30d39365 testsuite: fix is_amd64_regs_target This fix — and commit message — are mostly copied from it. --- gdb/testsuite/lib/gdb.exp | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) I'm not actually affected by this bug, and just noticed it because of the strange compilation error when building the aarch32.c test file: compiler exited with status 1 output is: /path/gdb/testsuite/temp/232375/aarch32.c:1:9: error: unknown type name 'mov' 1 | mov r0, r0 | ^~~ /path/gdb/testsuite/temp/232375/aarch32.c:2:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mov' 2 | mov r1, r1 | ^~~ It only affects aarch64 machines with the aarch64 "execution domain"¹ (i.e., the default one) using a toolchain configured to produce 32-bit binaries. Our aarch32 systems are containers using the linux32 command, so GDB and DejaGNU see armv8l as the architecture/"execution domain" and is_aarch32_target works correctly. ¹ See setarch(8) man page.