New attribute: Tag_RISCV_reserved_register

[kito-cheng]

Motivation

Tag_RISCV_reserved_register used for record reserved register information,
desiged for resolve checking compatibility between ABI subvariants like
overlay ABI.

Meaning

This attribute is a bit-vector of reserved register, but it can also
representation as a register list, syntax below:

RESERVED_REGS := '{' REG_LIST '}'

REG_LIST      := REG_LIST ',' REG_LIST
               | REG_RANGE
               | REG

REG_RANGE     := REG '-' REG

REG           := <register-name> | <abi-register-name> # e.g. x10, t3, f10 or fa2

For example: x6, x7, x8 and f10 are reserved, then the value of
Tag_RISCV_reserved_register is 0x400000001c1, and it also could be represent
as {x6, x7, x8, f10} or {x6-x8, f10}.

Merge Rule

It will report errors if link object files with different
Tag_RISCV_reserved_register values, but allowed link with object with and
without Tag_RISCV_reserved_register value, the final value will take from the
object which has set Tag_RISCV_reserved_register.

[jim-wilson]

The stuff about the register lists is a little confusing, as the encoding chosen for Tag_RISCV_reserved_register requires a bit vector. So I think you might be talking about the acceptable assembly input, or objdump/readelf output. But not the encoding in the object file. This is a little unclear the way it is worded. Maybe add something about human readable input/output can use the alternate syntax. Also not clear if this is the right place to document assembly syntax. Maybe that should be in the asm manual?

Otherwise this looks reasonable to me.

[jrtc27]

Given custom extensions start at 3072 this doesn't make sense in the current form IMO.

[jrtc27]

Also, a file without the tag being merged with a file with the tag is just asking for trouble.

[jrtc27]

Your grammar also parses ambiguously as you have REG_LIST on either side of the comma, even though the "operator" is associative so it doesn't really matter. I'd be inclined to express it as:

RESERVED_REGS ::= '{' REG_LIST '}'

REG_LIST      ::= REG_RANGE ',' REG_LIST
                | REG_RANGE

REG_RANGE     ::= REG '-' REG
                | REG

REG           ::= <register-name> | <abi-register-name> # e.g. x10, t3, f10 or fa2

and maybe also add | '{' '}' to RESERVED_REGS if the empty list is allowed to be written and/or encoded.

[jrtc27]

Should be plural

[kito-cheng]

Also, a file without the tag being merged with a file with the tag is just asking for trouble.

My thought is provide some flexible for human written asm file, but I admit that could be a trouble, I think in future we might add an extra asm directive to make this thing easier (e.g. .option overlay).

I'll update that later to remove the exception merge rule.

[kito-cheng]

@jim-wilson

The stuff about the register lists is a little confusing, as the encoding chosen for Tag_RISCV_reserved_register requires a bit vector. So I think you might be talking about the acceptable assembly input, or objdump/readelf output. But not the encoding in the object file. This is a little unclear the way it is worded. Maybe add something about human readable input/output can use the alternate syntax. Also not clear if this is the right place to document assembly syntax. Maybe that should be in the asm manual?

Thanks for the review comment, split human readable input/output part to asm manual sounds good to me, we don't have any word for .attribute for asm manual yet, it's a good opportunity to fill out that :P...

[edward-jones]

I have a patch for LLVM which implements this here: D113890

This is needed in order to reserve registers for use by the overlay engine.

[edward-jones]

I have a branch of my own which tries to incorporate the feedback from here (also a rebase). I can turn this into a pull request of its own if that's best?

https://github.com/edward-jones/riscv-elf-psabi-doc/tree/erj-reserved-register-attr

I agree that the assembler syntax/human readable format should be in the assembler manual.

As for the merging of objects files with/without the tag, I think best to disallow mixing entirely and then an option could be added later to explicitly supress that warning in cases where you're deliberately linking object files with different tags.

[kito-cheng]

Changes:

• Including @edward-jones's changes
• Rebase to master
• Move assembly syntax to riscv-asm-manual: Document .attribute reserved_registers riscv-asm-manual#74

[edward-jones]

Can I ask what the path forward is for this. In the psABI call someone (I can't remember who?) suggested that there may be a simpler solution for the overlay system, but I don't think they elaborated on what the solution was?

[kito-cheng]

IIRC Anders Berg (from IAR) said, he will give move detail next time.

[oferShinaar]

The PR is important for Overlay, but it is a generic solution for saving registers + the option to validate register usage between libs on link time.
We can say it is an alternative solution to clang -ffixed-xx (which btw is what we are currently using in Overlay)

We don't see any correlation between this PR and the "helper functions" or in a future new ABI.
Users can choose to use RISCV reserved register tag on any ABI.

[kito-cheng]

Hi Ofer:

The policy for psABI is we won't merge anything new stuffs before releasing 1.0, however I guess that might take another 2 or 3 month due to the release process, so I think maybe we could branch out 1.0, and then keep including new stuffs for master branch, however that need to discuss with @jrtc27 and @cmuellner in next Toolchain & Runtime TS Bi-Weekly Meeting (2/14).

[oferShinaar]

Hi Kito, Seem like a good idea to branch changes after 1.0. Thanks, Ofer From: Kito Cheng ***@***.***> Sent: Tuesday, 8 February 2022 11:23 To: riscv-non-isa/riscv-elf-psabi-doc ***@***.***> Cc: Ofer Shinaar ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-elf-psabi-doc] New attribute: Tag_RISCV_reserved_register (#195) Hi Ofer: The policy for psABI is we won't merge anything new stuffs before releasing 1.0, however I guess that might take another 2 or 3 month due to the release process, so I think maybe we could branch out 1.0, and then keep including new stuffs for master branch, however that need to discuss with @jrtc27<https://github.com/jrtc27> and @cmuellner<https://github.com/cmuellner> in next Toolchain & Runtime TS Bi-Weekly Meeting (2/14). — Reply to this email directly, view it on GitHub<#195 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJTYBZNF5K5V2YOXCM4XX2TU2DOIFANCNFSM474DRJAA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[jrtc27]

Temporarily forking the document risks leading to confusion, but even if that weren't an issue, handling things other than those for 1.0 takes away precious time from getting the release out the door. Let's just focus on what we need to rather than getting distracted by future things, especially those that are quite subjective like this.

[kito-cheng]

@jrtc27 :
I guess @oferShinaar is want to make sure the name and number is reserved and make sure their own implementation won't break (too much) in future.

So maybe we could give a label (maybe pre-approved-new-tag?) for that to mark that is kind of pre-approved for the tag name and tag number? and defer the merge until 1.0 is released.

[jrtc27]

Reserving relocation numbers requires reaching a consensus that the set of relocations is correct. I do not want to waste what little time I have pushing forward non-1.0 things.