From: "Maciej W. Rozycki" <macro@embecosm.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom de Vries <tdevries@suse.de>,
Simon Marchi <simon.marchi@efficios.com>,
gdb-patches@sourceware.org
Subject: [OB PATCH] gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp
Date: Sat, 29 Oct 2022 14:56:19 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.20.2210261710250.19931@tpp.orcam.me.uk> (raw)
In-Reply-To: <b4947f92-4dd3-ef51-7fed-1c542a156953@simark.ca>
Wrap an overlong line in the definition of `param_integer_error' in
gdb.guile/scm-parameter.exp. No functional change.
---
On Wed, 26 Oct 2022, Simon Marchi wrote:
> >>> FTR I'm still looking into it and like you I have hesitated to just paper
> >>> the issue over by allowing both outputs without first understanding what
> >>> is really going on here. I cannot rule out a distribution-specific patch
> >>> causing a discrepancy here, but I feel like tracking it down.
> >>>
> >>> NB guile 2.0.13 here, reporting as:
> >>>
> >>> guile (GNU Guile) 2.0.13
> >>> Packaged by Debian (2.0.13-deb+1-5.4)
> >>
> >> According to that version number, it looks like Ubuntu 20.04?
> >>
> >> https://packages.ubuntu.com/focal/guile-2.0
> >>
> >> I tried building on Ubuntu 20.04 against guile-2.0, and I see the same
> >> result as you. And when I try guile2.0 on Arch Linux (this package
> >> [1]), I also see the same result as you. So I must have tested it wrong
> >> previously.
> >>
> >> You can dig further if you want, but I'd be fine just accepting both
> >> outputs and saying that guile-2.0 outputs the additional ERROR: while
> >> subsequent versions do not.
> >>
> >
> > FWIW, I did the same here in commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0").
>
> Thanks, then I just went ahead and pushed this:
Thanks, though why such a rush to fix a benign test failure while the
review took months in the first place?
FWIW I have been struggling to get multiple versions of Guile compiled
and installed locally (easier) and then GDB built against each of them
(tougher). As it turns out our documentation is misleading. We have:
`--with-guile[=GUILE]'
Build GDB with GNU Guile scripting support. (Done by default if
libguile is present and found at configure time.) If your host
does not have Guile installed, you can find it at
`https://www.gnu.org/software/guile/'. The optional argument
GUILE can be a version number, which will cause `configure' to
try to use that version of Guile; or the file name of a
`pkg-config' executable, which will be queried to find the
information needed to compile and link against Guile.
(and similarly in `./configure --help'), so one could have thought
`--with-guile=2.0' will work. Well, not. You need to specify both the
name and the version, e.g.: `--with-guile=guile-2.0', which I find kind of
awkward: why would one want to have a Guile package under a name that is
not "guile"? I think documentation is sensible and it's implementation
that ought to be fixed.
But that is not enough. Still I got:
checking whether to use guile... guile-2.0
checking for pkg-config... /usr/bin/pkg-config
checking for usable guile from /usr/bin/pkg-config... checking for scm_set_automatic_finalization_enabled... no
configure: error: in `.../gdb':
configure: error: linking guile version guile-2.0 test program failed
See `config.log' for more details
make[1]: *** [Makefile:12496: configure-gdb] Error 1
This is because I have built local Guile as static libraries only and
dependencies are not pulled with the (incorrect) `pkg-config' invocation
we have in our configury.
I got these issues sorted now and will be posting fixes soon. With these
in place I have figured out that the message changed between Guile 2.0 and
2.2.
Last but not least here's a fix I committed as obvious to correct an
overlong line you have introduced with your change. While we do have an
exemption for TCL code, there's no need to make use of it here and these
long lines hit clarity of code badly. I have verified this test case to
still pass after my change.
Maciej
---
gdb/testsuite/gdb.guile/scm-parameter.exp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
gdb-test-scm-parameter-error-wrap.diff
Index: src/gdb/testsuite/gdb.guile/scm-parameter.exp
===================================================================
--- src.orig/gdb/testsuite/gdb.guile/scm-parameter.exp
+++ src/gdb/testsuite/gdb.guile/scm-parameter.exp
@@ -185,7 +185,9 @@ foreach_with_prefix kind {
set param_integer_error \
[multi_line \
"ERROR: In procedure set-parameter-value!:" \
- "(ERROR: )?In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 \\(expecting integer\\): #:unlimited" \
+ "(ERROR: )?In procedure gdbscm_set_parameter_value_x:\
+ Wrong type argument in position 2 \\(expecting integer\\):\
+ #:unlimited" \
"Error while executing Scheme code\\."]
set param_minus_one_error "integer -1 out of range"
set param_minus_two_range "integer -2 out of range"
next prev parent reply other threads:[~2022-10-29 13:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 16:43 [PATCH] gdb/testsuite: fix gdb.guile/scm-parameter.exp "wrong type argument" test pattern Simon Marchi
2022-10-24 23:22 ` Maciej W. Rozycki
2022-10-25 1:08 ` Simon Marchi
2022-10-26 7:15 ` Tom de Vries
2022-10-26 15:31 ` Simon Marchi
2022-10-29 13:56 ` Maciej W. Rozycki [this message]
2022-10-31 12:57 ` [OB PATCH] gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.2210261710250.19931@tpp.orcam.me.uk \
--to=macro@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
--cc=simon.marchi@efficios.com \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).