Re: [PATCH] Correct function prototype for REAL_EXIT and REAL__EXIT

On 1/28/25 02:30, Torbjorn SVENSSON wrote: On 2025-01-28 06:27, Jacob Bachmeyer wrote: On 1/26/25 10:59, Torbjorn SVENSSON wrote: [...] On 2025-01-26 02:51, Jacob Bachmeyer wrote: On 1/25/25 02:55, Torbjörn SVENSSON wrote: [...] As I understand, this is a shift in C dialect over the

Re: [PATCH] Correct function prototype for REAL_EXIT and REAL__EXIT

2025-01-26 02:51, Jacob Bachmeyer wrote: On 1/25/25 02:55, Torbjörn SVENSSON wrote: [...] 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 d

Re: [PATCH] Correct function prototype for REAL_EXIT and REAL__EXIT

On 1/26/25 17:31, Rob Savoye wrote: On Sat, Jan 25, 2025 at 07:51:44PM -0600, Jacob Bachmeyer wrote: 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

Re: [PATCH] Correct function prototype for REAL_EXIT and REAL__EXIT

-01-25 Torbjörn Svensson + + * testglue.c: Add missing argument to function prototype for + REAL_EXIT and REAL__EXIT. + 2024-10-20 Jacob Bachmeyer PR73907 diff --git a/testglue.c b/testglue.c index 06f4a90..348479a 100644 --- a/testglue.c +++ b/testglue.c @@ -48,12 +48,12

Re: How to debug, among other questions

On 12/30/24 14:17, Eduardo Costa wrote: Hi!, I'm new to dejagnu and would like to know, as I see the `debug.exp' file under `/usr/share/dejagnu', what is the 'tcl debugger' mentioned in this file that we can use to debug the scripts? Is it referring to `tkcon', `tcl-pro-debug', or other I don't

Re: [PATCH] dejagnu(1) and shell scripts

Stefan wrote: Hi Jacob! the dejagnu(1) launcher now first walks the PATH returned by `getconf PATH` (and then the user's $PATH) for an "sh" in search of a POSIX shell. Does this also fix your problem? Kind of. The getconf tool is missing in Guix, not only during the bootstrapping I'm tr

Re: [PATCH] dejagnu(1) and shell scripts (was: Catch errors properly, if whoami or who don't exist)

Stefan wrote: [...] By the way, I need another patch, as /bin is not existing in my case. I'm actually a bit wondering why all tools like awk, expect, tcl have a fallback without a path just to their executable name, but sh needs a fallback to /bin/sh. But anyway, this is a common problem p

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Stefan wrote: [...] In fact, how are you even running the dejagnu(1) and runtest(1) scripts if /bin/sh does not exist? Their #! lines refer to /bin/sh... In Guix there is an automatism to patch (only) all shebangs to the correct absolute paths. So you patch every script instead of install

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Maciej W. Rozycki wrote: On Fri, 6 Sep 2024, Jacob Bachmeyer wrote: By the way, I need another patch, as /bin is not existing in my case. I'm actually a bit wondering why all tools like awk, expect, tcl have a fallback without a path just to their executable name, but sh needs a fal

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Rob Savoye wrote: On 9/8/24 6:15 PM, Jacob Bachmeyer wrote: So the logs were not sitting on a shared server, then. Perhaps a notion of credit-where-credit-is-due to the testers? In those days we were still using UUCP over Telebit Trailblazer modems. :-) The shared server came by years

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Rob Savoye wrote: On 9/6/24 9:54 PM, Jacob Bachmeyer wrote: In the first place I was wondering why at all logname is needed. I can guess the reason for putting the user's login name into the log based on DejaGnu's history: DejaGnu originated at Cygnus, where the ability to easi

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Stefan wrote: Can you provide more information about your environment, in particular how whoami(1) failed? I'm playing around with the source bootstrap process of Guix¹. The built Binutils has some issue and I want to run its testsuite. There is no Coreutils at this stage but only gash-uti

Re: [PATCH] Catch errors properly, if whoami or who don't exist

Stefan wrote: Catch got passed a string in which the command substitution happened before, so it could not catch the error thrown by 'exec'. The string match for error messages afterwards was relying on an english language setting and did not even match the english error message of whoami from

Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

Hans-Peter Nilsson wrote: Date: Wed, 14 Aug 2024 20:58:04 -0500 From: Jacob Bachmeyer Reply-To: jcb62...@gmail.com [...] If this is correct, I will fix it in Git master. (The fix is trivial: change the "I" to "[Ii]" to accept both forms.) Yes, thanks; just do

Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

Hans-Peter Nilsson wrote: (CC to the dejagnu project as a heads-up) Regtested cris-elf with a fresh newlib checkout where 2640 libstdc++-v3 tests otherwise fail due to the stubbed newlib _getentropy. Ok to commit? -- >8 -- Newer newlib trigger warnings about certain functions not implemented (

Re: RFE: Allow for execution output to influence test result

DejaGnu already has the requested feature as far as I can tell. Rainer Orth wrote: In the GCC testsuite, there's quite a number of tests (mostly in gcc/testsuite/gcc.target/i386, but also on powerpc and x86_64) that check if the host CPU supports some ISA extension at runtime and currently just

Re: [PATCH] Use GFDL 1.3 or later text for man pages

Siddhesh Poyarekar wrote: From: Siddhesh Poyarekar Use the proper GFDL 1.3 or later license header for the man pages instead of the current stub, where the license version is unclear. * doc/dejagnu-help.1: Use a proper GFDL 1.3 or later header. * doc/dejagnu-report-card.1: Like

Re: Generalizing DejaGnu timeout scaling

Hans-Peter Nilsson wrote: On Wed, 3 Jan 2024, Jacob Bachmeyer wrote: Comments before I start on an implementation? I'd suggest to await the conclusion of the debate: I *think* I've proved that dg-timeout-factor is already active as intended (all parts of a test), specifi

Generalizing DejaGnu timeout scaling (was: Re: [PATCH DejaGNU/GCC 0/1] Support per-test execution timeout factor)

Maciej W. Rozycki wrote: On Wed, 3 Jan 2024, Hans-Peter Nilsson wrote: The test execution timeout is different from the tool execution timeout where it is GCC execution that is being guarded against taking excessive amount of time on the test host rather than the resulting test case execu

Re: [PATCH 0/4] Handle test execution timeout consistently across protocols

Maciej W. Rozycki wrote: On Tue, 12 Dec 2023, Jacob Bachmeyer wrote: A change for the timeout factor will follow. As it consists of a DejaGNU part and a GCC part I chose to send it separately so as not to cross-post this whole series between the DejaGNU and GCC mailing lists. Any

Re: [PATCH DejaGNU 1/1] Support per-test execution timeout factor

Maciej W. Rozycki wrote: Add support for the `test_timeout_factor' global variable letting a test case scale the wait timeout used for code execution. This is useful for particularly slow test cases for which increasing the wait timeout globally would be excessive. * baseboards/qemu.

Re: [PATCH 0/4] Handle test execution timeout consistently across protocols

Maciej W. Rozycki wrote: The intent is to avoid having to override the respective TCL procedures locally just to correct the timeout handling shortcomings in the versions shipped with DejaGNU. Upstreaming changes like these is very important because monkeypatching the framework is not and

Tidying the DejaGnu Git repository (was: Fixing problems reported by "git fsck")

[ANNOUNCEMENT: Some (ancient) tags in the DejaGnu Git repository *will* change and/or move in the near future.] Shahab Vahedi wrote: TL;DR; There are problems in internal structure of DejaGnu's git repo. A POSIX shell script is proposed at the end of this message that fixes them. During this f

Re: [PATCH] runtest: Allow multi-word arguments

Christoph Muellner wrote: From: Christoph Müllner A recent change (5fafcd43) introduced a command line argument cache, that ensures that command line arguments have a higher priority than configuration files. That cache uses the following code to save and restore: save_cmd_var: upvar

Re: [PATCH] runtest: Allow multi-word arguments

Christoph Muellner wrote: From: Christoph Müllner A recent change (5fafcd43) introduced a command line argument cache, that ensures that command line arguments have a higher priority than configuration files. That cache uses the following code to save and restore: save_cmd_var: upvar

Re: testsuite under wine

NightStrike wrote: On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer wrote: NightStrike wrote: [...] I did another little test to try to better understand your point. I ran a linux native testsuite under a simulator that just sets SIM to " ". This resulted in extra ^M's

Re: testsuite under wine

NightStrike wrote: On Wed, Jan 11, 2023 at 4:06 AM NightStrike wrote: On Tue, Jan 10, 2023 at 9:56 PM Jacob Bachmeyer wrote: NightStrike wrote: On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban wrote: Sure, I'd be interested how well my latest patch work

Re: testsuite under wine

NightStrike wrote: On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban wrote: Sure, I'd be interested how well my latest patch works for NightStrike. It should give us overview about how much conhost interferes with test results in practice when we get easy stuff out of the way. Generally, mo

Re: testsuite under wine

Jacek Caban wrote: On 1/7/23 04:58, Jacob Bachmeyer wrote: On 12/24/22 06:33, Jacob Bachmeyer wrote: Jacek Caban wrote: [...] Also my point was that if you capture the output sent by the application to the terminal and match that to a pattern, then any processing made by conhost could

Re: testsuite under wine

NightStrike wrote: [...] I did another little test to try to better understand your point. I ran a linux native testsuite under a simulator that just sets SIM to " ". This resulted in extra ^M's also, although many tests pass because they're already looking for \r\n to accommodate windows. So

Re: testsuite under wine

Jacek Caban wrote: Hi Jacob, Sorry for the delay. Not a problem. On 12/24/22 06:33, Jacob Bachmeyer wrote: Jacek Caban wrote: [...] The terminfo database access functions tparm(), tigetflag(), tigetnum(), and tigetstr() all return values to their callers for further processing and

Re: testsuite under wine

NightStrike wrote: On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote: NightStrike wrote: On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote: [...] So at least we know for sure that this particular instance of extra characters is coming from Wine. Maybe Wine can be

Re: testsuite under wine

Jacek Caban wrote: On 12/23/22 04:51, Jacob Bachmeyer wrote: Eric Pouech wrote: Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : I think that it would not be enough. The way Windows consoles work is that we manage complete internal screen buffer and emit output that synchronizes the buffer

Re: testsuite under wine

NightStrike wrote: On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote: NightStrike wrote: [...] Second, the problems with extra \r's still remain, but I think we've generally come to think that that part isn't Wine and is instead either the testsuite or deja. So

Re: testsuite under wine

Eric Pouech wrote: Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : I think that it would not be enough. The way Windows consoles work is that we manage complete internal screen buffer and emit output that synchronizes the buffer with Unix terminal inside conhost.exe process. It means that

Re: testsuite under wine

NightStrike wrote: [...] Second, the problems with extra \r's still remain, but I think we've generally come to think that that part isn't Wine and is instead either the testsuite or deja. So I'll keep those replies to Jacob's previous message. Most likely, it is a combination of the MinGW

Re: testsuite under wine

[Bringing the DejaGnu list back into the discussion...] Jacek Caban wrote: Hi all, I'm responsible for Wine changes that cause your problems. I'm also CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, see [1] if you're interested in the context. Recent Wine versions

Re: Pass the -noecho option to spawn

Jonathan Wakely wrote: On Tue, 20 Dec 2022 at 02:51, Jacob Bachmeyer wrote: Jonathan Wakely wrote: Is there a reason that dejagnu's local_exec proc doesn't use the -noecho option for spawning the command? Every log contains the spawned commands twice because dejagnu prin

Re: testsuite under wine

NightStrike wrote: On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer wrote: NightStrike wrote: On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote: [...] This is either a testsuite problem or an environment problem. The GNU Fortran I/O module certainly has interesting

Re: Pass the -noecho option to spawn

Jonathan Wakely wrote: Is there a reason that dejagnu's local_exec proc doesn't use the -noecho option for spawning the command? Every log contains the spawned commands twice because dejagnu prints it then spawn repeats it (with an annoying \r appended, making copy & paste from the logs more awk

Re: testsuite under wine

NightStrike wrote: On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote: [...] This is either a testsuite problem or an environment problem. The GNU Fortran I/O module certainly has interesting behavior here. Try setting TERM=dumb in the environment while running the testsuite. If that

Re: testsuite under wine

NightStrike wrote: On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig wrote: On 17.12.22 01:26, NightStrike wrote: On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote: On 16.12.22 03:20, NightStrike via Fortran wrote: When I run the testsuite under wine, I'm getting a lo

Re: Excluding FAILs from UNSUPPORTED test cases

Arsen Arsenović wrote: On Friday, 30 September 2022 04:02:25 CEST Jacob Bachmeyer wrote: Please keep me informed about the results of looking into those; if this has actually exposed bugs in the GCC testsuite, I may add (as a testsuite debugging aid) an option to run ${tool}-dg-prune in an

Re: Excluding FAILs from UNSUPPORTED test cases

Arsen Arsenović wrote: On Monday, 26 September 2022 03:11:43 CEST Jacob Bachmeyer wrote: The tests that it fixed probably need some attention in the form of moving some "preclean" steps to GCC's ${tool}-dg-test. I'll add giving them a look to my TODO. Please ke

Re: Excluding FAILs from UNSUPPORTED test cases

Arsen Arsenović wrote: Hi, On Sunday, 25 September 2022 06:24:06 CEST you wrote: Running ${tool}-dg-prune earlier works both ways, allowing the callback prune routine to also remove or modify any output that might confuse the message-matching mechanism. Really, given the documented (such as

Re: Excluding FAILs from UNSUPPORTED test cases

Arsen Arsenović wrote: Hi, On Saturday, 24 September 2022 06:24:56 CEST you wrote: But when it's unsupported because ${tool}-dg-prune returns "::unsupported::" the individual checks within the file still appear in the results. I realise that in the target selector case, the test is just skip

Re: Excluding FAILs from UNSUPPORTED test cases

Jonathan Wakely wrote: [...] Yes, this is a little surprising. If a test is UNSUPPORTED because it fails to match a target selector, then any dg-error or other directives in the test are ignored, and there are no PASS, XFAIL etc. lines for them in the results. If a target selector fails to m

Re: Excluding FAILs from UNSUPPORTED test cases

Arsen Arsenović wrote: Hi, While working on freestanding libstdc++, we came up with the idea to use a special error message to detect tests that use headers that don't work in freestanding, and mark them as unsupported by emitting ::unsupported:: from libstdc++-dg-test. I have not yet ha

Re: How to execute "runtest" with mult-threads?

白寒枫 wrote: Hi, dejagnu I am a contributer for GCC. After I fix some bugs in GCC, I often use dejagnu to test GCC by a command like "make check-gcc ..." and use "-j" to speed up. I want to verify a distributed version of GCC in openEuler, recently. I think I only use "runtest --srcdir /path

Re: Enhancement request: `--dry-run` flag for `runtest`

Eric Gallager wrote: Many command-line utilities have a "--dry-run" flag to print what would be done by running them without actually performing any changes. I was thinking one would be particularly useful for running the GCC testsuite (to put in RUNTESTFLAGS), since it is quite large and running

Re: Broken links in online HTML manual

Rob Savoye wrote: On 3/29/22 04:13, Jonathan Wakely wrote: All the links for configuration files at https://www.gnu.org/software/dejagnu/manual/index.html give a 404 error: https://www.gnu.org/software/dejagnu/manual/Local-configuration-file.html https://www.gnu.org/software/dejagnu/manual/Glo

Re: rhbz460153 - perror should not errcnt across test files

Martin Cermak wrote: Jacob, folks, I think the current Dejagnu codebase (4e4eb1534b4) contains a bug that was initially reported here: https://bugzilla.redhat.com/show_bug.cgi?id=460153 I am unable to find that commit in my repository. Are you sure that it is in Savannah? The bug cont

Re: dejagnu-1.6.3 make check failures

Martin Cermak wrote: Hi folks, running make check for dejagnu-1.6.3 on Fedora 34. I'm seeing test failures per attached runtest sum and log files. I'm wondering whether these issues are known. Looking at the open bug list, I don't seem to see a matching one. Thoughts? I was wondering how l

Re: [ANNOUNCE] DejaGnu 1.6.3 released

Andreas Schwab wrote: Where do I get the sign key for this release? It isn't one of the member keys , and the group release keyring is empty. The group release keyring should no longer be empty. I have just been given the

Re: [ANNOUNCE] DejaGnu 1.6.3 released

Andreas Schwab wrote: On Jun 21 2021, Jacob Bachmeyer wrote: The release signing key should be on the keyserver keys.gnupg.net. That host does not exist. That is strange. I was quite sure I had uploaded it there just before the release. What is the current recommended keyserver

Re: [ANNOUNCE] DejaGnu 1.6.3 released

Andreas Schwab wrote: Where do I get the sign key for this release? It isn't one of the member keys , and the group release keyring is empty. The release signing key should be on the keyserver keys.gnupg.net. It is in

Bug reporting assistance (was: Re: bug#49078: dejagnu-1.6.3 test failure)

baldu...@units.it wrote: (apologies: if this message doesn't get inserted properly into the thread, the thread I'm referring to is https://lists.gnu.org/archive/html/bug-dejagnu/2021-06/msg7.html) To link a mail into bug report N, please send it to n...@debbugs.gnu.org. For example, to ad

[ANNOUNCE] DejaGnu 1.6.3 released

After a long delay, a new maintainer, and a lengthy release candidate series spanning nearly three full months, we are pleased to announce the "Three Decades of DejaGnu" release of DejaGnu 1.6.3. What is DejaGnu? DejaGnu is a framework for testing other programs, with a variety

Last call for bug reports in 1.6.3 prerelease series

With the fifth release candidate in the 1.6.3 series, all known issues scheduled to be fixed in the 1.6.3 release are believed to be resolved and I have not received any new bug reports. This is the last call for bugs found in 1.6.3-rc5; if no release blocking bugs are found, I plan to issue t

DejaGnu 1.6.3 release candidate 5

Release candidate 5 for DejaGnu 1.6.3 has been uploaded to alpha.gnu.org at ftp://alpha.gnu.org/gnu/dejagnu/dejagnu-1.6.3-rc5.tar.gz>. Release candidate 5 should resolve the issues on Solaris systems. In the interim since release candidate 4, I have applied for and been granted access to the GC

DejaGnu 1.6.3 release candidate 4

Release candidate 4 for DejaGnu 1.6.3 has been uploaded to alpha.gnu.org at ftp://alpha.gnu.org/gnu/dejagnu/dejagnu-1.6.3-rc4.tar.gz>. Release candidate 4 continues efforts to address issues reported by Rainer Orth on Solaris systems: PR47382 should be (mostly) resolved in this release candidate

RFC: Possible change in DejaGnu/Automake integration

The discovery of bug#47382 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47382>) has led to follow-on effects and efforts to resolve this issue have led to an interesting question: how are existing projects communicating build/host/target triplets to their DejaGnu testsuites and would adding

DejaGnu 1.6.3 release candidate 3

Release candidate 3 for DejaGnu 1.6.3 has been uploaded to alpha.gnu.org at ftp://alpha.gnu.org/gnu/dejagnu/dejagnu-1.6.3-rc3.tar.gz>. Release candidate 3 continues efforts to address issues reported by Rainer Orth on Solaris systems: PR47382 should be (mostly) resolved in this release candida

DejaGnu 1.6.3 release candidate 2

Release candidate 2 for DejaGnu 1.6.3 has been uploaded to alpha.gnu.org at ftp://alpha.gnu.org/gnu/dejagnu/dejagnu-1.6.3-rc2.tar.gz>. Release candidate 2 addresses three issues reported by Rainer Orth on Solaris systems: PR47382 should be resolved in this release candidate, as the shell scripts

DejaGnu 1.6.3 release candidate 1

Release candidate 1 for DejaGnu 1.6.3 has been uploaded to alpha.gnu.org at ftp://alpha.gnu.org/gnu/dejagnu/dejagnu-1.6.3-rc1.tar.gz>. The 1.6.3 release collects the development work done over the past two years, fixing numerous bugs, adding new Tcl procedures under the "testsuite" and "testca

Re: Schedule for next release?

Kito Cheng wrote: Hi all: Last released version of dejagnu is 1.6.2 which is released on 2018-11, according to the release history the period is 1 release / ~1 year. So I would like to know if there is any schedule on release 1.6.3? Thanks :) I am working on it. The previous maintainer q

Re: [PATCH] Add baseboard for PRU simulator

Dimitar Dimitrov wrote: On сряда, 16 декември 2020 г. 5:41:23 EET Jacob Bachmeyer wrote: Dimitar Dimitrov wrote: I'm running [1] PRU regression tests using this baseboard definition and mainline Binutils, GCC, Newlib and GNU Simulator. [1] https://github.com/dinuxbg/gnupru/blob/m

Re: [PATCH] Fix dejagnu.texi dependency declaration

Dimitar Dimitrov wrote: On сряда, 16 декември 2020 г. 5:34:46 EET Jacob Bachmeyer wrote: Dimitar Dimitrov wrote: This fixes "make distcheck" on my Debian 10 system. Thanks; trivial patch applied. I also cleaned up some other details in the build files while I was

Re: [PATCH] Add baseboard for PRU simulator

Dimitar Dimitrov wrote: I'm running [1] PRU regression tests using this baseboard definition and mainline Binutils, GCC, Newlib and GNU Simulator. [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-pru.sh ChangeLog: * Makefile.am: Add pru-sim.exp. * Makefile.in:

Re: [PATCH] Fix dejagnu.texi dependency declaration

Dimitar Dimitrov wrote: This fixes "make distcheck" on my Debian 10 system. Thanks; trivial patch applied. I also cleaned up some other details in the build files while I was looking at them. -- Jacob

Re: WARNING: Couldn't find the global config file.

Rob Savoye wrote: On 12/3/20 10:05 PM, Jacob Bachmeyer wrote: My guess is that this was somehow related to the testing labs at Cygnus long ago, but I will consider this change for 1.7 and will probably do it if I do not find a reason to keep the warning. Yep. In the beginning

Re: WARNING: Couldn't find the global config file.

Tom Tromey wrote: Jonathan> The manual says "If DEJAGNU is set, but the file cannot be located, an Jonathan> error will be raised and runtest will abort." That makes sense, if I Jonathan> name a file that doesn't exist, I'm doing something wrong. But if I Jonathan> don't name any file, maybe that

Re: WARNING: Couldn't find the global config file.

Jonathan Wakely wrote: On 03/12/20 13:33 +, Jonathan Wakely wrote: The manual says "If DEJAGNU is set, but the file cannot be located, an error will be raised and runtest will abort." That makes sense, if I name a file that doesn't exist, I'm doing something wrong. Despite the manual sayin

Re: What does "Execution timeout is: $test_timeout" mean?

Jonathan Wakely wrote: On 02/12/20 21:48 -0600, Jacob Bachmeyer wrote: Jonathan Wakely wrote: Hi, [...] If I set test_timeout in ~/.dejagnurc or site.exp then I do indeed see the value change. But it doesn't do anything. I can set test_timeout to 2 second, and tests that sleep for 20 se

Re: What does "Execution timeout is: $test_timeout" mean?

Jonathan Wakely wrote: Hi, [...] If I set test_timeout in ~/.dejagnurc or site.exp then I do indeed see the value change. But it doesn't do anything. I can set test_timeout to 2 second, and tests that sleep for 20 seconds or more will still PASS and not timeout (as long as $tool_timeout is larg

Re: Driving DejaGNU from Linux for testing arm-none-eabi toolchain executed on Windows

Torbjorn SVENSSON wrote: Looking forward to any example on how to do a Canadian cross toolchain test. Whatever does work for this, I am very interested in the details because the documentation is seriously lacking and/or outdated here and I will improve this part of the manual. -- Jaco

Development progress announcement: 1.6.3 code freeze

DejaGnu is currently in the code freeze for the upcoming 1.6.3 release. We (Rob Savoye and I) are working to resolve some minor administrative issues before branching for a release candidate. Patches currently pending will be considered for development towards 1.6.4 or 1.7. -- Jacob

Re: [PATCH] Makefile.am: allow slashes in git branches

Jose E. Marchesi wrote: It is way common for git branches to feature slashes in their names. This patch modifies a sed invocation in Makefile.am to use a different command delimiter. Are there any characters that are actually not allowed in Git branch names or do I need to revise those comm

Re: AVR simulator support

Pip Cet wrote: I'm running the GCC testsuite on AVR using the simulator included in binutils-gdb, and an avr-sim.exp file, which essentially duplicates all the other *-sim.exp files. Is that the right way, or should I be using generic-sim.exp or multi-sim.exp? The multi-sim.exp file seems t

Re: DejaGnu unit testing protocol

David Malcolm wrote: On Wed, 2020-07-22 at 17:05 -0500, Jacob Bachmeyer wrote: [...] In terms of "other comments": FWIW within gcc, the jit.dg testsuite for libgccjit has a copy of host_execute ("fixed_host_execute") to workaround issues I've run into: https://gcc

DejaGnu unit testing protocol

I had been planning to look at this later, but fixing PR42399 brought this front-and-center. The DejaGnu unit testing protocol is not (yet) documented (will be fixed as part of PR42399) and there is a strange quirk in its handler. What produces lines with prefixes matching {[0-9][0-9]:..:..:}

Re: [PATCH] Add riscv-sim.exp

We are happy (in principle) to add this support to DejaGNU, however the FSF does not currently have a copyright assignment for changes to DejaGNU from SiFive or from you. I note that riscv-sim.exp has an FSF copyright notice, but we do not have the papers to substantiate that notice for contri

Re: [PATCH 0/3] Merge in gdb default_target_compile changes

b7c6 Mon Sep 17 00:00:00 2001 From: Jacob Bachmeyer Date: Sat, 20 Jun 2020 23:19:20 -0500 Subject: [PATCH 4/8] Document find_* procedures imported from GDB testsuite --- ChangeLog|6 ++ doc/dejagnu.texi | 47 +-- 2 files changed, 51 in

Re: GDB testsuite overrides default_target_compile and breaks

Tom Tromey wrote: Jacob> What is needed in brief: Jacob> (1) Merge the features of default_target_compile that the GDB Jacob> testsuite depends on upstream for 1.6.3. Jacob> (2) Find the actual extensibility that GDB needs here and add that Jacob> support to the default_target_compile rewrite sla

Re: [PATCH 0/3] Merge in gdb default_target_compile changes

Tom Tromey wrote: This series merges in gdb's changes to default_target_compile, updating them to follow newer conventions at the same time. I tested this using various parts of the gdb test suite (in particular Go and Rust). I also verified that, with this series in place, gdb does not use its

GDB testsuite overrides default_target_compile and breaks

. Rozycki wrote: [cc-ing Joel as the originator, and ] On Tue, 9 Jun 2020, Jacob Bachmeyer wrote: I ran a quick bisection and the culprit turned out to be: ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit commit ba60272a5ac6f6a7012acca03f596a6ed003f044 Author: Jacob Bachmeyer

Re: Proposed new API call: testcase group {begin|end}

Tom Tromey wrote: Jacob> Would passing a code block inhibit byte-compiliation? I have no idea. At least for gdb, I tend to doubt it would matter. Tcl's opportunistic JIT only applies to procedure bodies, so code running at top-level in a script file is never byte-compiled. Thanks for the sug

Re: New API call: "testsuite has api call" [renamed]

Jacob Bachmeyer wrote: The proposed form is simple: testsuite has api call As an example [testsuite has api call testsuite file] returns 1 as does [testsuite has api call testsuite has api call]. Test scripts are expected to use this call along the lines of: if { [testsuite has api call

Re: Proposed new API call: testcase group {begin|end}

Tom Tromey wrote: "Jacob" == Jacob Bachmeyer writes: Jacob> API call: testcase group begin Jacob> API call: testcase group end Jacob> Begin or end test group where is either a string that Jacob> may contain multiple /-delimited parts or a Tcl list that will

New API call: "testsuite has api call"

While planning support for the new XML output, I realized that the "testsuite file" API was introduced after 1.6.2, which means that checking for the existence of "testsuite" itself is sufficient to indicate that it is available, but "testsuite" throws an error if given an unrecognized subcomma

Proposed new API call: testcase group {begin|end}

The new XML output will have a concept of test groups. While the DejaGnu core can group tests by the scripts executed to run them, one test script can itself run multiple logically-distinct groups of tests. This new API call will also introduce a new multiplex entrypoint "testcase" distinguis

New XML output format

There is currently an experimental (and broken as of this writing; the DB schema has been changed but work on the new import tool is stalled) branch "psql" in the repository, where an improved database storage model is being developed. In the course of that development, the inadequacies of the

Ensuring that site.exp no longer overrides command line options

Recently, bug#41647 was reported and I have found that it is caused by (1) Automake writing a relative name for srcdir into site.exp if configure is invoked using a relative name, (2) overriding this with a command-line option specifying an absolute path in the "check" recipe because (3) Automa

Re: patches done

Rob Savoye wrote: I finished all the patches Jacob added to our savannah patch tracker. I did validate the ones that effected target configuration with my minimal cross testing setup, but would appreciate somebody with a more complex environment could give current 'master' a sanity check. I

Re: [PATCH 2/2] remote: Fix a stuck remote call pipeline causing testing to hang

Maciej W. Rozycki wrote: On Wed, 20 May 2020, Jacob Bachmeyer wrote: So the solution to the problem is twofold. First pending force-kills are not killed after `wait' if there are more than one PID in the list passed to `close_wait_program'. This follows the observation that if

Re: [PATCH 1/2] remote: Use `catch' in killing pending force-kills

Maciej W. Rozycki wrote: On Wed, 20 May 2020, Jacob Bachmeyer wrote: Index: dejagnu/lib/remote.exp === --- dejagnu.orig/lib/remote.exp +++ dejagnu/lib/remote.exp @@ -113,7 +113,10 @@ proc close_wait_program { program_id pid

Re: [PATCH 2/2] remote: Fix a stuck remote call pipeline causing testing to hang

Maciej W. Rozycki wrote: [...] So the solution to the problem is twofold. First pending force-kills are not killed after `wait' if there are more than one PID in the list passed to `close_wait_program'. This follows the observation that if there was only one PID on the list, then the proces

Re: [PATCH 1/2] remote: Use `catch' in killing pending force-kills

Maciej W. Rozycki wrote: --- lib/remote.exp |5 - 1 file changed, 4 insertions(+), 1 deletion(-) dejagnu-remote-close-wait-kill-catch.diff Index: dejagnu/lib/remote.exp === --- dejagnu.orig/lib/remote.exp +++ dejagnu/lib/re

Re: I volunteer

Rob Savoye wrote: On 5/18/20 2:16 PM, Jacob Bachmeyer wrote: My work on DejaGnu is one of my hobbies. However, DejaGnu is a relatively stable project, so I do not expect it to require much time. To adequately test DejaGnu, you need to be able to build and test the GNU toolchain

Re: [PING^3][PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada

Maciej W. Rozycki wrote: On Fri, 25 Oct 2019, Jacob Bachmeyer wrote: I have just sent a patch to the list that has been waiting in my local repository since June. It adds unit tests for the default_target_compile procedure, but currently verifies the broken Ada handling. Would you be

  1   2   3   >