From: liuzhensong <liuzhensong@loongson.cn>
To: WANG Xuerui <i.swmail@xen0n.name>
Cc: Xi Ruoyao <xry111@xry111.site>,
binutils@sourceware.org, xuchenghua@loongson.cn,
mengqinggang@loongson.cn, Fangrui Song <maskray@google.com>,
huangpei@loongson.cn
Subject: Re: [PATCH 1/5 v1] LoongArch: bfd: Add new reloc types.
Date: Wed, 20 Jul 2022 20:54:05 +0800 [thread overview]
Message-ID: <21960943-8432-f734-bd6e-4e2145507917@loongson.cn> (raw)
In-Reply-To: <f0b6a8e3-e6f6-d47f-35e0-481dbc929dad@xen0n.name>
在 2022/7/20 下午12:03, WANG Xuerui 写道:
> On 2022/7/20 10:07, liuzhensong wrote:
>>
>> Some relocation name changes make sense. But, how to name a name is a
>> matter of personal aesthetics, and it is difficult to satisfy
>> everyone. Does the name of the relocation matter? should we pay more
>> attention to the specific implementation? Remove useless and add
>> needed?
>>
> Names do matter. You can't expect to lower maintenance costs and
> barrier to entry for newcomers with "bad" names. I showed the original
> names in the patch to some of my colleagues (with no low-level
> programming experience; they are all application developers), and they
> invariably can't get the distinction of "LO12/HI20/LO20/HI12". I then
> showed them my proposal, granted they needed a little explanation as
> to what things like "SK12" mean, but after that they can immediately
> get the feel of the relocs ("ah, it's like for this purpose, put this
> part of imm into this slot").
>
> LoongArch is expected to remain niche, at least for the coming 3~5
> years, so you can't expect to have many people working on low-level
> nitty-gritty details like this. I personally don't think your team's
> composition is going to remain stable over the years, either; in
> either case, people come and go, so IMO there is indeed value in this
> bikeshedding. The community as a whole can work over concrete
> proposals of better naming, and I think my proposal serves as such a
> constructive starting point.
>
> Also, if you think the current names are more appropriate, with
> objective reasons, then *please communicate* your justification and
> thought behind them. We "outsiders" actually intend to cooperate, and
> have voiced our thoughts, but we don't know what you and your team
> think. For now all we have is this "LO12/HI20/LO20/HI12" and outsiders
> can draw no conclusion other than "hmm this is going to cause
> confusion". We really need to communicate more in the open for pushing
> things forward, constructively.
Your relocation is fine, but it's a bit long and complicated and
informative(personaly opinion). It seems unlikely to modify code just by
relocation name, there is necessary to understand the instructions
represented by relocation.
I made some adjustments to some relocations, then, LO12 and HI20
implement 32-bit relocation, xxx64_LO20 and xxx64_HI12 implement high
32bits of 64-bit relocation while low 32bits use LO12 and HI20. In my
opinion, it is enough to know what to do by name.
LO12 [11:0] HI20 [31:12] 64_LO20 [51:32] 64_HI12 [63:52] Changes,
1. B_R_L_GOT64_LO12 B_R_L_GOT_LO12
2. B_R_L_GOT64_HI20 B_R_L_GOT_HI20
3. B_R_L_TLS64_IE_LO12 B_R_L_TLS_IE_LO12
4. B_R_L_TLS64_IE_HI20 B_R_L_TLS_IE_HI20
5. B_R_L_TLS64_LD_HI20 B_R_L_TLS_LD_HI20
6. B_R_L_TLS64_GD_HI20 B_R_L_TLS_GD_HI20
Original name Suggested name
------------- --------------
B_R_L_B16 B_R_L_PCREL_SK16
B_R_L_B21 B_R_L_PCREL_SD5K16
B_R_L_B26 B_R_L_PCREL_SD10K16
B_R_L_ABS_LO12 B_R_L_ABS_0_SK12
B_R_L_ABS_HI20 B_R_L_ABS_12_SJ20
B_R_L_ABS64_LO20 B_R_L_ABS_32_SJ20
B_R_L_ABS64_HI12 B_R_L_ABS_52_SK12
B_R_L_PCALA_LO12 B_R_L_PCALA_0_SK12
B_R_L_PCALA_HI20 B_R_L_PCALA_12_SJ20
B_R_L_PCALA64_LO20 B_R_L_PCALA_32_SJ20
B_R_L_PCALA64_HI12 B_R_L_PCALA_52_SK12
B_R_L_GOT_PC_LO12 B_R_L_GOT_PCALA_0_SK12
B_R_L_GOT_PC_HI20 B_R_L_GOT_PCALA_12_SJ20
B_R_L_GOT64_PC_LO20 B_R_L_GOT_PCALA_32_SJ20
B_R_L_GOT64_PC_HI12 B_R_L_GOT_PCALA_52_SK12
1. B_R_L_GOT_LO12 B_R_L_GOT_ABS_0_SK12
2. B_R_L_GOT_HI20 B_R_L_GOT_ABS_12_SJ20
B_R_L_GOT64_LO20 B_R_L_GOT_ABS_32_SJ20
B_R_L_GOT64_HI12 B_R_L_GOT_ABS_52_SK12
B_R_L_TLS_LE_LO12 B_R_L_TLS_LE_ABS_0_SK12
B_R_L_TLS_LE_HI20 B_R_L_TLS_LE_ABS_12_SJ20
B_R_L_TLS_LE64_LO20 B_R_L_TLS_LE_ABS_32_SJ20
B_R_L_TLS_LE64_HI12 B_R_L_TLS_LE_ABS_52_SK12
B_R_L_TLS_IE_PC_LO12 B_R_L_TLS_IE_PCALA_0_SK12
B_R_L_TLS_IE_PC_HI20 B_R_L_TLS_IE_PCALA_12_SJ20
B_R_L_TLS_IE64_PC_LO20 B_R_L_TLS_IE_PCALA_32_SJ20
B_R_L_TLS_IE64_PC_HI12 B_R_L_TLS_IE_PCALA_52_SK12
3. B_R_L_TLS_IE_LO12 B_R_L_TLS_IE_ABS_0_SK12
4. B_R_L_TLS_IE_HI20 B_R_L_TLS_IE_ABS_12_SJ20
B_R_L_TLS_IE64_LO20 B_R_L_TLS_IE_ABS_32_SJ20
B_R_L_TLS_IE64_HI12 B_R_L_TLS_IE_ABS_52_SK12
B_R_L_TLS_LD_PC_HI20 B_R_L_TLS_LD_PCALA_12_SJ20
5. B_R_L_TLS_LD_HI20 B_R_L_TLS_LD_ABS_12_SJ20
B_R_L_TLS_GD_PC_HI20 B_R_L_TLS_GD_PCALA_12_SJ20
6. B_R_L_TLS_GD_HI20 B_R_L_TLS_GD_ABS_12_SJ20
next prev parent reply other threads:[~2022-07-20 12:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 8:43 liuzhensong
2022-07-18 8:43 ` [PATCH 2/5 v1] LoongArch:opcodes: " liuzhensong
2022-07-18 8:43 ` [PATCH 3/5 v1] LoongArch: gas: " liuzhensong
2022-07-18 8:43 ` [PATCH 4/5 v1] LoongArch: Move ifunc info to rela.dyn from rela.plt liuzhensong
2022-07-18 11:45 ` Xi Ruoyao
2022-07-18 16:27 ` Xi Ruoyao
2022-07-19 7:26 ` liuzhensong
2022-07-18 8:43 ` [PATCH 5/5 v1] LoongArch: Delete R_LARCH_NONE from dynamic info liuzhensong
2022-07-18 10:06 ` [PATCH 1/5 v1] LoongArch: bfd: Add new reloc types WANG Xuerui
2022-07-18 11:33 ` Xi Ruoyao
2022-07-18 12:11 ` WANG Xuerui
2022-07-18 12:18 ` WANG Xuerui
2022-07-19 3:57 ` Fangrui Song
2022-07-20 7:47 ` liuzhensong
2022-07-20 2:07 ` liuzhensong
2022-07-20 4:03 ` WANG Xuerui
2022-07-20 5:19 ` Xi Ruoyao
2022-07-20 12:54 ` liuzhensong [this message]
2022-07-19 7:32 ` liuzhensong
2022-07-20 2:42 ` liuzhensong
2022-07-19 4:29 ` Xi Ruoyao
2022-07-19 5:40 ` Xi Ruoyao
2022-07-19 6:31 ` 刘振松
2022-07-19 6:34 ` Xi Ruoyao
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=21960943-8432-f734-bd6e-4e2145507917@loongson.cn \
--to=liuzhensong@loongson.cn \
--cc=binutils@sourceware.org \
--cc=huangpei@loongson.cn \
--cc=i.swmail@xen0n.name \
--cc=maskray@google.com \
--cc=mengqinggang@loongson.cn \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/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).