Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Simon Marchi <simark@simark.ca>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCHv2] Fix setting breakpoints or stepping on line 65535
Date: Sun, 29 Dec 2019 20:32:00 -0000	[thread overview]
Message-ID: <20191229203253.GP3865@embecosm.com> (raw)
In-Reply-To: <b368f488-e6a6-b35d-a6f6-0f18be44ee00@simark.ca>

* Simon Marchi <simark@simark.ca> [2019-12-29 14:45:13 -0500]:

> On 2019-12-02 1:04 p.m., Bernd Edlinger wrote:
> > Hi Andrew,
> > 
> > On 12/1/19 11:08 PM, Andrew Burgess wrote:
> >> * Bernd Edlinger <bernd.edlinger@hotmail.de> [2019-11-24 11:54:23 +0000]:
> >>
> >>> Hi,
> >>>
> >>> this removes code that is present from the very first git revisison
> >>> 7b4ac7e1ed2c4616bce56d1760807798be87ac9e from 1988.  It was in the
> >>> gdb/dbxread.c at the time (and makes more sense for dbx line info format
> >>> since line numbers are 16-bit entities in that debug format and debugging
> >>> files with more than 65535 lines would not work anyway) but moved from
> >>> there to gdb/buildsym.c which is used for dwarf line info as well, and
> >>> excluding an arbitrary line number does certainly not make sense nowadays.
> >>>
> >>>
> >>> Thanks
> >>> Bernd.
> >>
> >>> From f202ae765b72ad6d17600eb661993a63191309f7 Mon Sep 17 00:00:00 2001
> >>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> >>> Date: Sat, 23 Nov 2019 07:37:26 +0100
> >>> Subject: [PATCH 1/2] Fix setting breakpoints or stepping on line 65535
> >>>
> >>
> >> Bernd,
> >>
> >> Thanks for looking into this, and especially thanks for adding a test!
> >>
> >> Normally you should include the git commit message and ChangeLog along
> >> with your patch submission so that these can be reviewed too. 'git
> >> format-patch' and 'git send-email' can be useful for this, if you can
> >> get them setup.
> >>
> > 
> > Okay, I added changelog messages for gdb/ChangeLog and gdb/testsuite/ChangeLog,
> > and improved the commit messages.
> > I hope you can handle the format-patch files as attachments. 
> > 
> >> Given the age of the code you're removing I think this change sounds
> >> reasonable.  I assume there's no test that covers why this code should
> >> be there, so you see no regressions with this code removed?
> >>
> > 
> > No, there were no regressions (last full test on 24-11-19).
> > 
> >> I have a couple of minor issues with the test.  If you address those
> >> and repost with commit message and ChangeLog this can be approved.
> >>
> > 
> > Fixed the test.
> > 
> > Thanks a lot for your review.
> > Is it OK for trunk?
> 
> Thanks Bernd, this is OK.  For the future, I think it would be reasonable to put the
> fix and the test in the same patch.  It would also help somebody wondering why we have
> such a weird test trace it back to the fix, and the explanation you have put in the first
> patch.  But it's also fine like this.

I place more value on having tests and changes in the same commit - I
find it more useful the other way around, when I find some code I
don't understand and I figure out which commit it came from, having
the tests in the same commit means it is easy to know "this test"
should check "this code".

If the test and changes are separate I have to do more work. Boo!

For this reason, if you've not already pushed this patch, could you
collapse the test and change into a single commit please before
pushing.

Thanks,
Andrew


  reply	other threads:[~2019-12-29 20:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-24 11:54 [PATCH] " Bernd Edlinger
2019-12-01 20:46 ` [PING] " Bernd Edlinger
2019-12-01 22:08 ` Andrew Burgess
2019-12-02 18:04   ` [PATCHv2] " Bernd Edlinger
2019-12-14 13:57     ` [PING] " Bernd Edlinger
2019-12-28  8:46       ` [PING**2] " Bernd Edlinger
2019-12-29 19:46     ` Simon Marchi
2019-12-29 20:32       ` Andrew Burgess [this message]
2019-12-29 20:41         ` Simon Marchi
2019-12-29 21:24           ` Bernd Edlinger

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=20191229203253.GP3865@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gdb-patches@sourceware.org \
    --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