Closed yetingk closed 1 month ago
cc @ved-rivos @jrtc27 @asb
@aswaterman The reason I suggest keep both is I don't want make older tool become non-conformance with this asm manual, but maybe we could using different way/wording to prevent that?
I still believe the extension should have been defined in a way that doesn't break existing practices, and it's pretty weird to have tail
change which register it uses based on what extensions you happen to have enabled. That sounds like asking for trouble if people are assuming the register that tail
clobbers (thinking about custom calling conventions when branching to a non-preemptible symbol), too, given it has been explicitly specified as being t1...
Without thinking through all the implications, my instincts are that it is much better to change the PLT implementation (which is technically also specified today, but really shouldn't be, the code should just be an example of a possible implementation, as application code shouldn't know/care about it) than to change the semantics of pseudo-instructions.
Looks good to me.
Whatever change is made here should also be reflected in the table.
Done.
NOTE: public review period for zicfiss and zicfilp are ended, waiting for ratification flow and then we will merge this.
Zicfiss, Zicfilp were ratified in June.
Rebased to fix conflicts.
This change is to make
tail
conform with software guarded jump of Zicfilp. The reason to not chooset1
as the label register is thatt1
is also as.got.plt
offset of_dl_runtime_resolve
in PLT.