Hi Jacub,
Thanks for the review.
On 2025-01-26 02:51, Jacob Bachmeyer wrote:
On 1/25/25 02:55, Torbjörn SVENSSON wrote:
Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
---
ChangeLog | 5 +++++
testglue.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c6804f0..23bca8e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2025-01-25 Torbjörn Svensson <torbjorn.svens...@foss.st.com>
+
+ * testglue.c: Add missing argument to function prototype for
+ REAL_EXIT and REAL__EXIT.
+
2024-10-20 Jacob Bachmeyer <j...@gnu.org>
PR73907
diff --git a/testglue.c b/testglue.c
index 06f4a90..348479a 100644
--- a/testglue.c
+++ b/testglue.c
@@ -48,12 +48,12 @@ extern void exit (int);
#endif
#ifdef REAL_MAIN
-extern void REAL_EXIT ();
+extern void REAL_EXIT (int);
extern void REAL_ABORT ();
extern int REAL_MAIN (int argc, char **argv, char **envp);
#endif
#ifdef REAL__EXIT
-extern void REAL__EXIT ();
+extern void REAL__EXIT (int);
#endif
static int done_exit_message = 0;
As I understand, this is a shift in C dialect over the years if it is a
real issue. Originally, an empty argument list did not mean "no
arguments" but "unspecified arguments". To declare "no arguments" you
must explicitly write "func(void)" in C.
It was like this, but with C23, it's no longer the case.
In C23, it's considered an error to call a function where the function
prototype does not match the call site (only exception to this is the
elipse AFAIK).
While I seem to recall that the C standard has always specified exit(3)
to take an "int" argument, it was also implicitly intended for programs
hosted on Unix and a freestanding board might not use an exit code and
simply halt or shut down when "exit()" is called.
I don't know if you are allowed to define "exit()" (without arguments)
and still be complaint with the C standard. If you are not complaint
with the C standard, then all bets are off. :)
If you want the code to work more or less in the same grey zone as
before, I guess it could change to this:
#if __STDC_VERSION__ >= 202311L
extern void REAL_EXIT (int);
#else
extern void REAL_EXIT ();
#endif
I can send a V2 with this if you think that is better.
This also looks like you might actually know what testglue.c actually
does and how it is used. Could you enlighten me on that or at least
point me to an example of something that uses it? I am currently
reluctant to touch it because I do not know what changing it might break.
The testglue.c is used whenever you need to get status of a test case,
but you cannot get the exit code directly by invoking the test
application. A typical example is when you use a simulator or run tests
on an embedded target though a GDB server.
While running the gcc testsuite, you would specify that the testglue.c
file is needed in your board definition using:
set_board_info needs_status_wrapper 1
This will build the testglue.c to an object file before the tests are
started and then include the object file in the link phase of every
executable.
When the target executes the executable, the argument to "exit" will be
printed like this:
*** EXIT code 0
0 here is the result of calling exit(0).
If the executable instead calls "abort", then the status code 4242 is used:
*** EXIT code 4242
The TCL code then picks up thise magic string and replaces the exit code
from the simulator (for example) with this value in the string and then
the rest of the testsuite code does not need to know that there were an
alternative path to get the result of the test case from the target.
The technique used to override exit, abort and main using the --wrap
argument to the GNU linker.
There is probably a lot more details that I've missed here to why it's
implemented the way it is, but at least this gives you an idea of when
and why it's may be needed.
Kind regards,
Torbjörn
-- Jacob
