public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Caroline Tice <cmtice@google.com>, "H.J. Lu" <hjl.tools@gmail.com>
Cc: Eric Christopher <echristo@google.com>,
	Tom Tromey <tom@tromey.com>,
	Caroline Tice via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5
Date: Wed, 15 Jul 2020 22:34:58 -0400	[thread overview]
Message-ID: <fe767f7f-1007-b5a9-4a2d-39e6e63cc81a@simark.ca> (raw)
In-Reply-To: <CABtf2+T0XjYr3x8SSX-KRrr_K9ccSnN4-=xrkzRUfeeaif91DQ@mail.gmail.com>

On 2020-07-15 6:35 p.m., Caroline Tice wrote:
> Thank you for that suggestion!
> 
> It turns out that I CAN create the .o file with clang, then use that
> for the basis of my test; linking it with GCC works and gives the
> results I expect (it fails with ToT GDB , but passes with my patch).
> 
> In order to make this work, however, I have to make a small change to
> gdb/testsuite/lib/gdb.exp (in build_executable_from_specs, I have to
> check to see if the source file is already an object file before
> trying to compile it into an object file, and if it is an object file,
> copy it into the proper directory)l
> 
> Should I add that (and the .o version of the test case) to this patch,
> or should I make it a separate patch?  If the latter (which is what
> feels right to me), then if this patch can receive final approval (and
> someone can commit it, as I do not have write privileges to the GDB
> code base), then I will submit the subsequent patch to replace the
> current test with the .o version and update  gdb/testsuite/lib/gdb.exp
> to make it work.

I'd be fine merging the patch with the current test and keep working on
improving the test coverage.  I think that we'll need indeed need to do
a bit of infrastructure work to improve the testing of DWARF5 in general.

Can you please provide a final patch version where you mention in the commit
message how to run the test in order to provoke a failure.  Please make sure
to include the compiler version as well (output of `clang --version`) because,
as you said, the code compilers output changes with time.  So in order to be
able to reproduce the failure, it would be useful to know the compiler version.

I'm not sure what you mean by "the .o version of the test case".  Do you
mean check-in the .o in the git repository?  We currently don't check in
binary test artifacts for GDB.  However, I'm of the opinion that it could
be useful sometimes (like here).  But we'd need to have a discussion
about this first, how we want to do that, which guidelines to follow.

About this comment, in your other message:

> I did try, originally, to make this an assembly code test, as I do
> understand that compilers change, and the code they generate today is
> not necessarily the code they generate tomorrow.  Unfortunately the
> GNU assembler cannot process the DWARF v5 that is generated by clang
> (e.g. it can't handle file numbers that start at 0 instead of 1 (which
> is in the DWARF v5 spec, and which clang generates); and I have not
> been able to figure out a way to get GDB test to use the clang
> integrated assembler.

Just wondering, doesn't gcc emit at least *some* DWARF 5 by now?  If so,
can't the GNU assembler deal with it?

Simon

  reply	other threads:[~2020-07-16  2:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 17:16 [PATCH] " Caroline Tice
2020-06-01 20:33 ` Tom Tromey
2020-06-02 17:04   ` Caroline Tice
2020-06-03 14:49     ` Tom Tromey
2020-06-04 21:39       ` Caroline Tice
2020-06-09 23:32         ` Caroline Tice
2020-06-16 15:37           ` Caroline Tice
2020-06-18 20:27           ` Tom Tromey
2020-06-23 19:04             ` Caroline Tice
2020-07-01  0:09               ` Caroline Tice
2020-07-01  0:34               ` Simon Marchi
2020-07-01  0:36                 ` Simon Marchi
2020-07-01 19:57                   ` Caroline Tice
2020-07-02  5:41                     ` Simon Marchi
2020-07-03 22:47                       ` [PATCH V3] " Caroline Tice
2020-07-04  5:11                         ` Simon Marchi
2020-07-09 15:48                           ` [PATCH V4] " Caroline Tice
2020-07-11 17:54                             ` Simon Marchi
2020-07-14 15:47                               ` [PATCH V5] " Caroline Tice
2020-07-15  2:04                                 ` Simon Marchi
2020-07-15  3:15                                   ` Simon Marchi
2020-07-15 16:57                                     ` Caroline Tice
2020-07-15 17:04                                       ` H.J. Lu
2020-07-15 22:35                                         ` Caroline Tice
2020-07-16  2:34                                           ` Simon Marchi [this message]
2020-07-16  4:46                                             ` Caroline Tice
2020-07-16 15:41                                               ` Simon Marchi
2020-07-16 15:46                                                 ` Caroline Tice
2020-07-16 16:09                                                   ` 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=fe767f7f-1007-b5a9-4a2d-39e6e63cc81a@simark.ca \
    --to=simark@simark.ca \
    --cc=cmtice@google.com \
    --cc=echristo@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=tom@tromey.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).