> Date: Thu, 15 Jan 2026 22:51:37 +0000 (UTC) > From: Joseph Myers <[email protected]>
> On Thu, 15 Jan 2026, Hans-Peter Nilsson wrote: > > > > It does cope: it skips the tests that can't work on such a target and > > > continues with the rest of the testsuite. It simply shows an ERROR that > > > indicates a possible bug in the test machinery - in this case, a bug in > > > the board file that can best be fixed in the board file. > > > > That's pushing the blame! The board file does not emit an > > error; that comes from somewhere in the middle of dejagnu. > > See for yourself: cris-sim.exp is in recent dejagnu > > releases. I believe the same thing happens for other > > *-sim.exp. The gcc testsuite needs to handle this without > > causing an ERROR to be emitted. > > sim.exp is part of the board file implementation. I don't think the > distinction between config/ in DejaGnu, baseboards/ in DejaGnu and > externally provided board files is particularly significant here. It certainly is to the casual board.exp author. > Given the lack of an actual DejaGnu interface for a board file to declare > lack of genuine support for <board>_exec, the only plausible way to avoid > an ERROR entirely in GCC would be to monkey-patch either perror or > sim_exec around the relevant attempts to run GDB. I think we do an > unfortunate amount of monkey-patching of bits of DejaGnu in the GCC > testsuite as is - it has a high risk of causing problems with future > DejaGnu versions - and avoiding those ERRORs is not a proportionate reason > to add more. What? No! The presence of an ERROR is *usually* a sign of a typo in a testsuite patch that causes an early-abort for parts of the test-suite, a common error that is otherwise hard to detect. If an ERROR can be avoided by, say, a few lines of "monkey-patching", that helps. I think an obvious conclusion is that your r16-6780-g620c85fb709d27 and r16-6781 are flawed, perhaps downright buggy. Please fix. Skipping the "native" gdb runs for simulator targets shouldn't be too hard. brgds, H-P
