public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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


  


  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).