From: Carl Love <cel@us.ibm.com>
To: Simon Marchi <simark@simark.ca>,
Bruno Larsen <blarsen@redhat.com>,
gdb-patches@sourceware.org,
UlrichWeigand <Ulrich.Weigand@de.ibm.com>,
pedro@palves.net
Cc: luis.machado@arm.com, cel@us.ibm.com
Subject: RE: [PATCH v4] Fix reverse stepping multiple contiguous PC ranges over the line table.
Date: Tue, 16 May 2023 15:54:27 -0700 [thread overview]
Message-ID: <ef14cc6d9b09808d714abc4217a0544ceed1c586.camel@us.ibm.com> (raw)
In-Reply-To: <0943e12c-049d-f8b0-c4c5-8816b1be1e45@simark.ca>
Simon:
On Thu, 2023-05-11 at 12:01 -0400, Simon Marchi wrote:
> >
<snip>
> I'd like to help reviewing this, but I don't have much time at the
> moment, so just a few comments on one test to start with.
>
> > + This test is used to test the reverse-step and reverse-next
> > instruction
> > + execution for a source line that contains multiple function
> > calls. */
> > +
> > +void
> > +func1 ()
> > +{
> > +} // END FUNC1
>
> Use /* */ for comments, for consistency with the rest of the code
> base.
>
OK, changed all instances of // comment.
> > +
> > +void
> > +func2 ()
> > +{
> > +} // END FUNC2
> > +
> > +int main ()
> > +{
> > + int a, b;
> > + a = 1;
> > + b = 2;
> > + func1 (); func2 ();
> > + a = a + b; // START REVERSE TEST
> > +}
> >
<snip>
> > +
> > +require supports_reverse
> > +
> > +# This test uses the gcc no-column-info command which was added in
> > gcc 7.1.
> > +if {![test_compiler_info {gcc-*}]
> > + || [test_compiler_info {gcc-[1-6]-*}]} {
> > + return
> > +}
>
> I would prefer not to filter out by compiler explicitly like that.
> It would be useful for the test to run with other compilers too.
OK, implemented the gdb_compile options. Moved the specific gcc
version test there.
>
> > +
> > +proc run_tests {} {
> > + global srcfile
<snip>
> > +
> > +set srcfile func-map-to-same-line.c
> > +set executable func-map-to-same-line
> > +
> > +# test with gcc column info enabled
> > +set options [list debug additional_flags=]
> > +
> > +if {[build_executable "failed to prepare" $executable $srcfile
> > $options] == -1}\
> > + {
> > + return -1
> > +}
> > +
> > +clean_restart $executable
> > +
> > +with_test_prefix "with-column-info" {
> > + run_tests
> > +}
>
> So, the above assumes that the compiler generates column-info by
> default, which has not historically been the case for GCC (it started
> to
> emit columns by default with version 8, according to my
> tests). Other
> compilers may choose to not emit them by default.
>
> I think it would make sense to make gdb_compile recognize the new
> "column-info" and "no-column-info" options, which would translate to
> the
> right flags for the given compiler. gdb_compile already handles the
> nitty gritty details of choosing compiler flags for specific compiler
> versions. This way, individual tests don't contain compiler flags
> that
> are possibly compiler-specific.
OK, I think I have this implemented as suggested. It does seem to
work. I added both gcc and clang support. Per the link to clang which
does have line info options.
I put the new gdb_compile option support in a separate patch, followed
by the updated "Fix reverse stepping multiple.... " patch.
I tested the test case with:
make check RUNTESTFLAGS='CC_FOR_TARGET=clang GDB=.../gdb gdb.reverse/func-map-to-same-line.exp' > out
and
make check RUNTESTFLAGS='GDB=.../gdb gdb.reverse/func-map-to-same-line.exp' > out
I looked in the gdb/testsuite/gdb.log file to verify that the compiler
line (gcc or clang) explicitly has the -gcolumn-info for the first
test and -gno-column-info for the second test. The expected number
of success were seen for the test with gcc and clang. It all looks
like it works.
>
> > +
> > +#test with gcc column info disabled
> > +set options [list debug additional_flags=-gno-column-info]
> > +
> > +if {[build_executable "failed to prepare" $executable $srcfile
> > $options] == -1}\
> > + {
> > + return -1
> > +}
> > +
> > +set $executable executable_without_column_info
> > +clean_restart $executable
> > +
> > +with_test_prefix "no-column-info" {
> > + run_tests
> > +}
>
> This would probably be a good use for foreach_with_prefix (if you can
> make it work), to make things more compact:
>
> foreach_with_prefix with_column_info {yes no} {
> }
>
> ... or something like that.
Changed to the foreach_with_prefix.
Thanks for the review.
Will post version 5 as a series of two patches.
Carl
next prev parent reply other threads:[~2023-05-16 22:54 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 20:59 [PATCH] " Carl Love
2023-05-02 14:15 ` Bruno Larsen
2023-05-02 15:40 ` Carl Love
2023-05-02 15:42 ` Bruno Larsen
2023-05-11 15:11 ` Simon Marchi
2023-05-03 9:53 ` Bruno Larsen
2023-05-04 2:55 ` Carl Love
2023-05-04 9:24 ` Bruno Larsen
2023-05-04 14:52 ` Carl Love
2023-05-04 2:55 ` [PATCH v2] " Carl Love
2023-05-04 15:59 ` [PATCH v3] " Carl Love
2023-05-05 14:59 ` Luis Machado
2023-05-05 16:10 ` Carl Love
2023-05-10 13:47 ` Bruno Larsen
2023-05-10 17:16 ` Carl Love
2023-05-10 17:32 ` [PATCH v4] " Carl Love
2023-05-11 16:01 ` Simon Marchi
2023-05-11 16:23 ` Bruno Larsen
2023-05-11 17:28 ` Simon Marchi
2023-05-16 22:54 ` [PATCH 1/2] " Carl Love
2023-06-19 17:11 ` Simon Marchi
2023-06-22 16:52 ` Carl Love
2023-06-23 17:44 ` Simon Marchi
2023-06-23 19:41 ` Carl Love
2023-06-23 20:04 ` [PATCH 1/2 ver 2] " Carl Love
2023-07-06 15:07 ` Carl Love
2023-05-16 22:54 ` [PATCH 2/2 v5] " Carl Love
2023-05-25 15:08 ` Carl Love
2023-06-08 16:36 ` Carl Love
2023-06-19 17:58 ` Simon Marchi
2023-06-22 20:38 ` Carl Love
2023-06-22 20:39 ` Carl Love
2023-06-23 17:49 ` Simon Marchi
2023-06-23 20:04 ` Carl Love
2023-06-23 20:04 ` [PATCH 2/2 v6] " Carl Love
2023-05-16 22:54 ` Carl Love [this message]
2023-05-11 7:52 ` [PATCH v3] " Bruno Larsen
-- strict thread matches above, loose matches on Subject: below --
2022-05-06 8:55 [PATCH, v4] " Luis Machado
2022-05-06 15:04 ` [PATCH,v4] " Bruno Larsen
2022-05-06 16:46 ` [PATCH, v4] " Carl Love
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=ef14cc6d9b09808d714abc4217a0544ceed1c586.camel@us.ibm.com \
--to=cel@us.ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=blarsen@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--cc=pedro@palves.net \
--cc=simark@simark.ca \
/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).