Mandatory/optional merging of build attributes #352
Comments
|
64 seems like an arbitrary limit. If we want to do this it should probably follow the odd/even approach and use something like bit 1 to indicate whether it's optional (with special cases for existing attributes that don't fit that). |
|
.ARM.attributes uses modular arithmetic. I originally used |
|
Ah I missed the (mod 128), that works (and effectively is equivalent, just uses bit 6 instead of bit 1) |
|
I like the general idea, it sounds like more easier to linker to handle unknown attributes :) |
MaskRay
changed the title
MaskRay
added a commit
to llvm/llvm-project
that referenced
this issue
Dec 8, 2022
Currently we take the first SHT_RISCV_ATTRIBUTES (.riscv.attributes) as the output. If we link an object without an extension with an object with the extension, the output Tag_RISCV_arch may not contain the extension and some tools like objdump -d will not decode the related instructions. This patch implements Tag_RISCV_stack_align/Tag_RISCV_arch/Tag_RISCV_unaligned_access merge as specified by https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#attributes For the deprecated Tag_RISCV_priv_spec{,_minor,_revision}, dump the attribute to the output iff all input agree on the value. This is different from GNU ld but our simple approach should be ok for deprecated tags. `RISCVAttributeParser::handler` currently warns about unknown tags. This behavior is retained. In GNU ld arm, tags >= 64 (mod 128) are ignored with a warning. If RISC-V ever wants to do something similar (riscv-non-isa/riscv-elf-psabi-doc#352), consider documenting it in the psABI and changing RISCVAttributeParser. Like GNU ld, zero value integer attributes and empty string attributes are not dumped to the output. Reviewed By: asb, kito-cheng Differential Revision: https://reviews.llvm.org/D138550
kito-cheng
added a commit
that referenced
this issue
Jan 30, 2023
kito-cheng
added a commit
that referenced
this issue
Jan 30, 2023
It's mandatory when (tag number % 128) < 64 and optional when (tag number % 128) >= 64. Fix #352
|
Created PR for this: #360 |
kito-cheng
added a commit
that referenced
this issue
Feb 20, 2023
It's mandatory when (tag number % 128) < 64 and optional when (tag number % 128) >= 64. Fix #352
ilovepi
pushed a commit
to ilovepi/riscv-elf-psabi-doc
that referenced
this issue
Mar 21, 2023
It's mandatory when (tag number % 128) < 64 and optional when (tag number % 128) >= 64. Fix riscv-non-isa#352
veselypeta
pushed a commit
to veselypeta/cherillvm
that referenced
this issue
Jun 6, 2024
Currently we take the first SHT_RISCV_ATTRIBUTES (.riscv.attributes) as the output. If we link an object without an extension with an object with the extension, the output Tag_RISCV_arch may not contain the extension and some tools like objdump -d will not decode the related instructions. This patch implements Tag_RISCV_stack_align/Tag_RISCV_arch/Tag_RISCV_unaligned_access merge as specified by https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#attributes For the deprecated Tag_RISCV_priv_spec{,_minor,_revision}, dump the attribute to the output iff all input agree on the value. This is different from GNU ld but our simple approach should be ok for deprecated tags. `RISCVAttributeParser::handler` currently warns about unknown tags. This behavior is retained. In GNU ld arm, tags >= 64 (mod 128) are ignored with a warning. If RISC-V ever wants to do something similar (riscv-non-isa/riscv-elf-psabi-doc#352), consider documenting it in the psABI and changing RISCVAttributeParser. Like GNU ld, zero value integer attributes and empty string attributes are not dumped to the output. Reviewed By: asb, kito-cheng Differential Revision: https://reviews.llvm.org/D138550
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am concerned with the use of build attributes but I think it's useful noting down a GNU ld arm behavior regarding to
.ARM.attributesmerging.For a tag number
tag, iftag%128 < 64, the attribute is considered mandatory and GNU ld unaware of it reports an error (which will change the exit status to 1); otherwise, (tag%128 >= 64), the attribute is considered optional: there is a warning but the link will succeed (--fatal-warningscan upgrade the warning to an error).For RISC-V, it's perhaps useful specifying whether it's necessary to emit a warning/error when all input files with an attribute have the same value. Personally I think that's not useful. When GNU ld sees an unknown attribute only in one input, it doesn't give a warning/error.
The text was updated successfully, but these errors were encountered: