From: Michael Chastain <mec.gnu@mindspring.com>
To: jimb@redhat.com, cagney@redhat.com, ezannoni@redhat.com
Cc: gdb@sources.redhat.com
Subject: gdb.mi/*.exp and absolute line numbers
Date: Thu, 05 Aug 2004 09:20:00 -0000 [thread overview]
Message-ID: <4111FC04.nailD7G1U3QKS@mindspring.com> (raw)
Ouch! I'm pulling on this loose thread, and a whole yard of the test
suite unravelled! I need some help.
Here is the situation:
(1) gcc HEAD has a new warning:
incompatible implicit declaration of built-in function.
(2) gcc warnings make the callers of gdb_compile bomb out.
(3) the way to fix the warning is to add the right #include <...> lines.
(4) i fixed all the instances in gdb.base/*.c.
(5) the problem is also in:
gdb.mi/basics.c gdb.mi/gdb701.c gdb.mi/var-cmd.c
(6) none of those files have a copyright notice
So I try adding a copyright notice to gdb.mi/basics.c. Boom, twenty
gdb.mi/*.exp scripts regress because they depend on absolute line
numbers:
mi-break.exp mi-cli.exp mi-diassemble.exp mi-eval.exp mi-file.exp
mi-return.exp mi-simplerun.exp mi-stack.exp mi-stepi.exp mi-watch.exp
mi2-break.exp mi2-cli.exp mi2-disassemble.exp mi2-eval.exp
mi2-file.exp mi2-return.exp mi2-simplerun.exp mi2-stack.exp
mi2-stepi.exp mi2-watch.exp
I'm disconcerted.
The natural fix is to use gdb_get_line_number in gdb.mi/*.exp. However,
gdb_get_line_number uses the CLI commands "list" and "search". I can't
find any MI equivalents.
But I don't see why gdb_get_line_number has to talk to gdb at all. I
think it could just be implemented in native tcl: open the file, read
each line, match the search string. Then gdb_get_line_number would work
with all user interfaces.
Can you remember the reason that gdb_get_line_number talks to gdb
rather than doing its own scanning? Perhaps the reason was just
"it's easier to talk to gdb than to write a bunch of tcl".
So my proposal is:
rewrite gdb_get_line_number in tcl
(either clone the function or rewrite existing implementation)
add gdb_get_line_number to gdb.mi/*.exp
add copyright notices to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
add #include lines to gdb.mi/{basics.c,gdb701.c,var-cmd.c}
... so the the gdb test suite will work with gcc HEAD
Another way out. Less work, but cheesier: put the copyright notices for
basics.c, gdb701.c, and var-cmd.c in a separate COPYRIGHT file, with a
note that these files have absolute line numbers and cannot easily be
edited.
Ideas?
Michael C
next reply other threads:[~2004-08-05 9:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 9:20 Michael Chastain [this message]
2004-08-05 13:23 ` Daniel Jacobowitz
2004-08-06 6:26 ` Michael Chastain
2004-08-05 14:34 ` Jim Blandy
2004-08-05 16:02 ` Michael Chastain
2004-08-06 8:24 ` Eli Zaretskii
2004-08-06 9:41 ` Michael Chastain
2004-08-06 14:46 ` Andrew Cagney
2004-08-06 16:06 ` Michael Chastain
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=4111FC04.nailD7G1U3QKS@mindspring.com \
--to=mec.gnu@mindspring.com \
--cc=cagney@redhat.com \
--cc=ezannoni@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=jimb@redhat.com \
/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).