public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon@arm.com>
To: Jan Beulich <jbeulich@suse.com>, Mark Harmstone <mark@harmstone.com>
Cc: binutils@sourceware.org, Tamar.Christina@arm.com,
	nickc@redhat.com, pinskia@gmail.com,
	Richard.Earnshaw@foss.arm.com, nightstrike@gmail.com,
	wej22007@outlook.com, zac.walker@linaro.org
Subject: Re: [PATCH 1/7] Fix size of external_reloc for pe-aarch64
Date: Mon, 9 Jan 2023 10:22:45 +0100	[thread overview]
Message-ID: <5cacce21-6eb9-fd6e-9497-006b076fb171@arm.com> (raw)
In-Reply-To: <3fb4611d-46ee-fe35-748c-238b4d71fff8@suse.com>



On 1/9/23 09:11, Jan Beulich wrote:
> On 06.01.2023 18:51, Mark Harmstone wrote:
>> On 6/1/23 09:47, Christophe Lyon wrote:
>>> Hi!
>>>
>>> I am not a maintainer, but would you mind adding proper commit messages describing what each patch does (or intends to)?
>>>
>>> Thanks,
>>>
>>> Christophe
>>
>> Hi Christophe,
>>
>> This is a resubmission of a patch set from a few days ago, because of a change that Tamar wanted. If you're interested in the discussion behind each patch, it's available in the mailing list archives.
> 
> I'm afraid pointing to list archives for explanations on patches isn't a good
> approach. Once committed, such links will not be easy to (re-)establish.
> Other projects are quite a bit more demanding towards the content of commit
> messages, but I guess some minimal level of explanation wants to be in the
> average binutils patch as well.
> 

That's what I meant I think, thanks for rephrasing :-)

I can't find guidelines on how to contribute patches for binutils, but 
they are similar to GCC's and GDB's. If you just run 'git log' in a 
binutils clone, you'll see what we mean: in addition to short a summary 
(title), commit messages include a description of what the commit does 
and why this is the right change.

It's great if all your changes are obvious for Nick, but they are not 
for others like me ;-)

For instance this patch 1/7 only says "Fix size of external_reloc for 
pe-aarch64", so why is the removal of 
SWAP_IN_RELOC_OFFSET/SWAP_OUT_RELOC_OFFSET and r_offset needed?

I did check the list archives, so if I'm not mistaken this is third 
iteration of this patch series? (I saw 1/5 and 1/8 in December, then 
this one in January). The first iteration had an introduction message 
which led to a discussion with Jan and Tamar, and I think an updated 
version of that message would help here, when others will have to try to 
understand these patches in whatever future time ;-)

Also as Jan mentioned on your testsuite patches, can you describe why we 
have to skip so many of them? Jan seems to think that they could be 
adjusted to cope with both formats intead.

Thanks,

Christophe

> Jan

  reply	other threads:[~2023-01-09  9:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06  1:25 Mark Harmstone
2023-01-06  1:25 ` [PATCH 2/7] Skip ELF-specific tests when targeting pe-aarch64 Mark Harmstone
2023-01-06  8:11   ` Jan Beulich
2023-01-06 17:48     ` Mark Harmstone
2023-01-09  7:59       ` Jan Beulich
2023-01-06  1:25 ` [PATCH 3/7] Skip big-obj test for pe-aarch64 Mark Harmstone
2023-01-06  8:12   ` Jan Beulich
2023-01-06  1:25 ` [PATCH 4/7] Add pe-aarch64 relocations Mark Harmstone
2023-01-06  1:25 ` [PATCH 5/7] Add .secrel32 for pe-aarch64 Mark Harmstone
2023-01-06  1:25 ` [PATCH 6/7] Add aarch64-w64-mingw32 target Mark Harmstone
2023-01-06  1:25 ` [PATCH 7/7] gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64 Mark Harmstone
2023-01-06  9:47 ` [PATCH 1/7] Fix size of external_reloc " Christophe Lyon
2023-01-06 17:51   ` Mark Harmstone
2023-01-09  8:11     ` Jan Beulich
2023-01-09  9:22       ` Christophe Lyon [this message]
2023-01-09 18:03         ` Mark Harmstone
2023-01-10  8:58           ` Jan Beulich
2023-01-10 23:32             ` Mark Harmstone

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=5cacce21-6eb9-fd6e-9497-006b076fb171@arm.com \
    --to=christophe.lyon@arm.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=Tamar.Christina@arm.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    --cc=mark@harmstone.com \
    --cc=nickc@redhat.com \
    --cc=nightstrike@gmail.com \
    --cc=pinskia@gmail.com \
    --cc=wej22007@outlook.com \
    --cc=zac.walker@linaro.org \
    /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).