Clarify the relationship between extensions. #723

kito-cheng · 2021-08-26T06:10:54Z

Update:

2021/9/6: Add zvamo and zvlsseg.

V extension require F and D, does it means implies? current ISA spec[1] only use implies and didn't appear any require, so I would like having more explicitly clarification for that word.
Can Zvl*b use without V, zve32* or zve64*?
Are these valid combinations? or it's valid but just meaningless, because it won't effect the minimal VLEN?
- V with zvl32b, zvl64b
- Zve64 with zvl32b
Are these valid combinations?
- V with zve32* or zve64*
- Any combination two different zve* extensions .
Can zvamo and zvlsseg use without V, zve32* or zve64*?

[1] https://github.com/riscv/riscv-isa-manual/blob/draft-20210825-d068b76/src/naming.tex#L148

The text was updated successfully, but these errors were encountered:

kito-cheng · 2021-08-26T06:39:00Z

Few more thing want to clarify:

Are these valid combinations?
- V with zve32* or zve64*
- Any combination two different zve* extensions .

zakk0610 · 2021-09-01T08:47:07Z

Does V extension passed to -march should imply at least Zvl128b? (The V vector extension requires that VLEN ≥ 128.)

zakk0610 · 2021-09-01T08:52:43Z

Can Zvlb use without V, zve32 or zve64*?

In other words, the question is "Does Zvl*b passed to -march should imply the V extension?"

aswaterman · 2021-09-01T20:42:03Z

Yes, I think V should imply Zvl128b.

kito-cheng · 2021-09-03T07:19:03Z

Changes:
2021/9/8: Update note for ELF attribute.

Hmmm...toolchain still need clarification, but before we got a formal clarification, I written down my understanding and my guess, and we gonna to implement that on toolchain.

zvl<x>b implied zvl<y>b if x > y, e.g. zvl256b implied zvl128b, zvl64b and zvl32b.
v implied zvl128b, Zve64* implied zvl64b and Zve32* implied zvl32b.
v with zvl32b is valid combination but minimal VLEN still 128 due to v implied zvl128b.
Zve64 with zvl32b is valid combination but minimal VLEN still 64 due to Zve64 implied zvl64b.
v with any zve* extension is valid combination is valid, but still same as v, e.g. v + zve32x = v
Different Zve* extension can be appear in arch string, but we only take the info from the biggest extension, e.g.
- zve64x + zve32x = zve64x
- zve64d + zve32f = zve64d
- zve64d + zve64f = zve64d
require means toolchain will report error and abort if the requirement not satisfied, e.g. toolchain will report error for rv32iv rather than interpret that as rv32ifdv
Zvl*b require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

Note for ELF attribute:

Tag_RISCV_arch always emit fully expanded form, e.g. v will expand to v1p0_zvl128b1p0_zvl64b1p0_zvl32b1p0_zvlsseg1p0_zve64d1p0_zve64f1p0_zve64x1p0_zve32f1p0_zve32x1p0.

Nelson1225 · 2021-09-03T07:57:22Z

Hmmm...toolchain still need clarification, but before we got a formal clarification, I written down my understanding and my guess, and we gonna to implement that on toolchain.

zvl<x>b implied zvl<y>b if x > y, e.g. zvl256b implied zvl128b, zvl64b and zvl32b.

v implied zvl128b, Zve64* implied zvl64b and Zve32* implied zvl32b.

v with zvl32b is valid combination but minimal VLEN still 128 due to v implied zvl128b.

Zve64 with zvl32b is valid combination but minimal VLEN still 64 due to Zve64 implied zvl64b.

v with any zve* extension is valid combination is valid, but still same as v, e.g. v + zve32x = v

Different Zve* extension can be appear in arch string, but we only take the info from the biggest extension, e.g.

zve64x + zve32x = zve64x

zve64d + zve32f = zve64d

zve64d + zve64f = zve64d

require means toolchain will report error and abort if the requirement not satisfied, e.g. toolchain will report error fr rv32iv rather than interpret that as rv32ifdv

Zvl*b require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

Addition rule for ELF attribute:

zvl*b extension must present at Tag_RISCV_arch attribute if v or zve* extension there.

Only emit largest zvl*b to Tag_RISCV_arch attribute, e.g. zvl256b + zvl128b, then we only emit zvl256 to attribute.

For v and zve*, only emit biggest extension to Tag_RISCV_arch.

My understanding is the same, especially agree with that we only need to take the information from the biggest/largest zve/zvl extensions.

Nelson1225 · 2021-09-03T08:05:12Z

Oh forgot to mention that - the linker should have the same reduced architecture string for zve and zvl. For example, there are two objects, one has zve64x, and another has zve32x. If we link the two objects, then the output architecture string should only have zve64x, since zve32x is covered by it.

jrtc27 · 2021-09-05T21:32:11Z

If the canonical form of Zfoo32b + Zfoo64b is Zfoo64b only then things don't work, because then you risk a kernel or run-time linker seeing it has Zfoo64b and not thinking that satisfies a Zfoo32b binary because it doesn't also see Zfoo32b, and you'd need to bake in extra logic to teach it about all those special cases.

The canonical (exploded) form for Zfoo32b + Zfoo64b should be Zfoo32b_Zfoo64b. Just as the canonical (exploded) form for F+D is FD. This is longer but things "just work"; having implicit extensions in the machine-processed arch strings just causes headaches. That's for the human-facing strings only.

kito-cheng · 2021-09-06T13:14:17Z

Updated:
Add one more item:

Can zvamo and zvlsseg use without V, zve32* or zve64*?

kito-cheng · 2021-09-06T13:15:29Z

Also add one more item to toolchain implementation note:

zvamo and zvlsseg require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

Nelson1225 · 2021-09-07T03:30:13Z

Also add one more item to toolchain implementation note:

zvamo and zvlsseg require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

According to the previous implementation and comments,
riscvarchive/riscv-binutils-gdb#219

The zvamo and zvlsseg can be used without v, so I think v shouldn't be required to be specified for them.

jim-wilson · 2021-09-07T17:20:53Z

The question here is does zvamo require v, or does it imply v. I think it is simpler if it requires v. Likewise with zvlsseg.

Hsiangkai · 2021-09-08T05:56:05Z

Hmmm...toolchain still need clarification, but before we got a formal clarification, I written down my understanding and my guess, and we gonna to implement that on toolchain.

zvl<x>b implied zvl<y>b if x > y, e.g. zvl256b implied zvl128b, zvl64b and zvl32b.

v implied zvl128b, Zve64* implied zvl64b and Zve32* implied zvl32b.

v with zvl32b is valid combination but minimal VLEN still 128 due to v implied zvl128b.

Zve64 with zvl32b is valid combination but minimal VLEN still 64 due to Zve64 implied zvl64b.

v with any zve* extension is valid combination is valid, but still same as v, e.g. v + zve32x = v

Different Zve* extension can be appear in arch string, but we only take the info from the biggest extension, e.g.

zve64x + zve32x = zve64x

zve64d + zve32f = zve64d

zve64d + zve64f = zve64d

require means toolchain will report error and abort if the requirement not satisfied, e.g. toolchain will report error fr rv32iv rather than interpret that as rv32ifdv

I don't agree with it. Extension should be able to be specified stand alone. For example, users could specify rv64id without f. Why are we not able to specify v only? That means the only way to specify v is fdv.

Zvl*b require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

Addition rule for ELF attribute:

zvl*b extension must present at Tag_RISCV_arch attribute if v or zve* extension there.

Only emit largest zvl*b to Tag_RISCV_arch attribute, e.g. zvl256b + zvl128b, then we only emit zvl256 to attribute.

For v and zve*, only emit biggest extension to Tag_RISCV_arch.

kito-cheng · 2021-09-08T08:44:34Z

I don't agree with it. Extension should be able to be specified stand alone. For example, users could specify rv32id without f. Why are we not able to specify v only? That means the only way to specify v is fdv.

F and D extension are both floating point extension, one for single precision and one for double precision, which is highly related.

But for the case of vector operation, it's not obviously relationship between vector and floating point like single precision and double precision.

That behavior will result -march=rv64ifvequal to -march=rv64ifdv, rv64ifv have no d, that means user didn't want d extension, but toolchain implied enabled d because v, in this case, user should either use zve64f or explicitly enabled d , both are possible expected behavior for user, but we never known which one is user's intention, just report error to let user explicitly choose the right way is better IMO.

My intention to prevent require those non-trivial and not obvious knowledge for toolchain user, just like we are trying to release the canonical order hell for the -march option.

kito-cheng · 2021-09-08T15:32:05Z

@jrtc27

If the canonical form of Zfoo32b + Zfoo64b is Zfoo64b only then things don't work, because then you risk a kernel or run-time linker seeing it has Zfoo64b and not thinking that satisfies a Zfoo32b binary because it doesn't also see Zfoo32b, and you'd need to bake in extra logic to teach it about all those special cases.

The canonical (exploded) form for Zfoo32b + Zfoo64b should be Zfoo32b_Zfoo64b. Just as the canonical (exploded) form for F+D is FD. This is longer but things "just work"; having implicit extensions in the machine-processed arch strings just causes headaches. That's for the human-facing strings only.

My intention was want to reduce the size of Tag_RISCV_arch, but after I write down a arch string with all ratified ext. with crypto, vector and bitmanip, it seems reduce size seems not so useful - it's still long but introduce too many rule need to handle, so I think let keep full expanded version to keep the rule simple.

Full expanded version:
"rv64i2p1_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zicsr2p0_zifencei2p0_zba1p0_zbb1p0_zbc1p0_zvl128b1p0_zvl64b1p0_zvl32b1p0_zvlsseg1p0_zve64d_zve64f_zve64x_zve32f_zve32x_zbkb1p0_zbkc1p0_zbkx1p0_zknd1p0_zkne1p0_zknh1p0_zksed1p0_zksh1p0_zkr1p0_zkm1p0_zks1p0_zk1p0_zkt1p0"

Reduced version:
"rv64i2p1_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zicsr2p0_zifencei2p0_zba1p0_zbb1p0_zbc1p0_zvl128b1p0_zvlsseg1p0_zkn1p0_zkn1p0_zks1p0"

nick-knight · 2021-09-08T16:44:41Z

@kito-cheng

Can zvamo and zvlsseg use without V, zve32* or zve64*?

I don't see Zvamo mentioned anywhere in the v1.0-rc1 spec. I don't think we need to support it.

I don't know what to say about "standalone Zvlsseg". I can't imagine that is an intended design point.

On a related note, I think the spec should just drop the Zvlsseg ISA string: I see no need to standardize a name for this subset. It certainly made sense when it was optional, but nowadays it is included in all the standard extensions. However, I've suggested this multiple times to the task group and it's never been changed, so I suppose its persistence is intentional.

kito-cheng · 2021-09-08T17:17:13Z

@kito-cheng

Can zvamo and zvlsseg use without V, zve32* or zve64*?

I don't see Zvamo mentioned anywhere in the v1.0-rc1 spec. I don't think we need to support it.

@nick-knight

I don't know what to say about "standalone Zvlsseg". I can't imagine that is an intended design point.

On a related note, I think the spec should just drop the Zvlsseg ISA string: I see no need to standardize a name for this subset. It certainly made sense when it was optional, but nowadays it is included in all the standard extensions. However, I've suggested this multiple times to the task group and it's never been changed, so I suppose its persistence is intentional.

Oh, thanks for point out that, that actually give me wrong impression is: Zvlsseg is a standalone
subset...

Read the spec again, zve* and v both has this sentence, so yes, that should be gone on the toolchain side since all extension are support...

The V extension supports all vector load and store instructions (Section Vector Loads and Stores), except the V extension does not support EEW=64 for index values when XLEN=32.

Hsiangkai · 2021-09-09T01:45:19Z

I don't agree with it. Extension should be able to be specified stand alone. For example, users could specify rv32id without f. Why are we not able to specify v only? That means the only way to specify v is fdv.

F and D extension are both floating point extension, one for single precision and one for double precision, which is highly related.

But for the case of vector operation, it's not obviously relationship between vector and floating point like single precision and double precision.

That behavior will result -march=rv64ifvequal to -march=rv64ifdv, rv64ifv have no d, that means user didn't want d extension, but toolchain implied enabled d because v, in this case, user should either use zve64f or explicitly enabled d , both are possible expected behavior for user, but we never known which one is user's intention, just report error to let user explicitly choose the right way is better IMO.

The worry is based on the assumption that v implies f and d. What if v does not imply f and d in the tool implementation? Users will specify what users want explicitly and there is no confusion. So,

If users only use integer vector operations, they could specify rv64iv without error messages.
If users use single-floating point vector operations, they will specify rv64ifv without error messages.
If users use double-floating point vector operations, they will specify rv64idv without error messages.

To enforce users to specify fdv for vector extension, it causes confusion from users' perspective, especially when users only use integer vector operations and see the error messages for rv64iv.

I think arch string is already complex. We have no need to add additional rules on it.

My intention to prevent require those non-trivial and not obvious knowledge for toolchain user, just like we are trying to release the canonical order hell for the -march option.

zakk0610 · 2021-09-09T02:21:04Z

In 1.0, I think users should use rv64i_zve*x if they only want to use integer vector operation.
I guess it's why the requirement The V extension requires the scalar processor to implement the F and D extensions, and implements all vector floating-point instructions and Zve*x are in the same commit 808a6f8.

nick-knight · 2021-09-09T02:27:41Z

There is already considerable momentum in this regard. Table 27.1 in Vol. 1 defines an "implies" relation on various extensions, for example, Q => D => F => Zicsr. In this case we might add V => D.

I note that toolchains implement a superset of this relation. For example, Clang/LLVM happily assembles this:

void foo(void) { asm ("csrrs x1, 17, x0"); }

with -march=rv32i, despite csrrs being part of the Zicsr extension [godbolt link].

EDIT: the toolchain folks have informed us below that this behavior is due to a backwards-incompatible change between i2p0 and i2p1 which is still being addressed.

kito-cheng · 2021-09-09T02:38:09Z

@nick-knight the fact is LLVM still implement i ext 2.0, which base extension still include zicsr and zifencei, you can try -march=rv32i_zcisr for clang, that result unsupported standard user-level extension 'zcisr', split zicsr and zifencei from baseline ISA is really annoying backward incompatible change...

kito-cheng · 2021-09-09T02:41:04Z

For GNU toolchain, @Nelson1225 and me has implement that on upstream for a while, which included in GCC 11, but that not available on https://godbolt.org/ :(

kito-cheng · 2021-09-09T02:49:42Z

There is already considerable momentum in this regard. Table 27.1 in Vol. 1 defines an "implies" relation on various extensions, for example, Q => D => F => Zicsr. In this case we might add V => D.

Yeah, but I am prefer to make sure this write down to the implies column, before that I treat require and implies are different.

Hsiangkai · 2021-09-16T03:15:00Z

Changes:

2021/9/8: Update note for ELF attribute.
Hmmm...toolchain still need clarification, but before we got a formal clarification, I written down my understanding and my guess, and we gonna to implement that on toolchain.

zvl<x>b implied zvl<y>b if x > y, e.g. zvl256b implied zvl128b, zvl64b and zvl32b.

v implied zvl128b, Zve64* implied zvl64b and Zve32* implied zvl32b.

v with zvl32b is valid combination but minimal VLEN still 128 due to v implied zvl128b.

Zve64 with zvl32b is valid combination but minimal VLEN still 64 due to Zve64 implied zvl64b.

v with any zve* extension is valid combination is valid, but still same as v, e.g. v + zve32x = v

Different Zve* extension can be appear in arch string, but we only take the info from the biggest extension, e.g.

zve64x + zve32x = zve64x

zve64d + zve32f = zve64d

A question about the rule. Why not emit an error message for the case. You do not know what the users want if they specify both zve* extensions in the arch string. I think the situation is similar to rv64if_zve64d or rv64id_zve64f. I agree we should expand it in the ELF attributes, but for human-facing string, should we restrict users to only specify v or one of zve* extensions?

zve64d + zve64f = zve64d

require means toolchain will report error and abort if the requirement not satisfied, e.g. toolchain will report error for rv32iv rather than interpret that as rv32ifdv

Zvl*b require either v or zve* extension, otherwise it's invalid arch, toolchain will report error.

Note for ELF attribute:

Tag_RISCV_arch always emit fully expanded form, e.g. v will expand to v1p0_zvl128b1p0_zvl64b1p0_zvl32b1p0_zvlsseg1p0_zve64d1p0_zve64f1p0_zve64x1p0_zve32f1p0_zve32x1p0.

Removed Zvlsseg extension name as segment load/stores are required in all standard vector extensions. Affects #723.

kasanovic · 2021-09-18T01:15:48Z

General rule is that extension names imply the things they require, and we take union of all implied features. This simplifies model when string is built up in pieces in different places, with multiple repeated additions of same extension. After vector spec isout, plan to revisit the naming chapter to clear this up.

aswaterman · 2021-10-22T11:27:51Z

RISC-V specs use the verb "depend" to describe the relationship between e.g. D and F. The Naming chapter makes it clear that dependence relationships can be used to shorten ISA strings: https://github.com/riscv/riscv-isa-manual/blob/399c9a759eb4540a65c60e2cc236164821ff2346/src/naming.tex#L46

This thread demonstrates that using the alternate verb "require" is causing confusion, so I've fixed the spec to use the standard verb. e8594a7 and 6fedb86

* Recognized zve* and zvl* extensions. - zve*: zve64d, zve64f, zve64x, zve32f and zve32x. - zvl*: zvl32b, zvl64b, zvl128b, zvl256b, zvl512b, zvl1024b, zvl2048b, zvl4096b, zvl8192b, zvl16384b, zvl32768b and zvl65536b. * Spec said that v requires f and d, zve64d requires d, zve64f and zve32f require f. However, according to the issue 723, [riscvarchive/riscv-v-spec#723] The general rule is that extension names imply the things they require. Therefore, the current imply rules should be as follows, - v imply f and d. - zve64d imply d. - zve64f and zve32f imply f. - zvamo imply a. Besides, consider the implicit zve and zvl extensions, - v imply zve64d and zvl128b. - zve64* imply the corresponding zve32*. For example, zve64f imply zve32f, and zve64x imply zve32x. - zve*d imply zve*f and zve*x. For example, zve64d imply zve64f and zve64x. - zve*f imply zve*x. For example, zve64f imply zve64x. - zve64* imply zvl64b, and zve32* imply zvl32b. - The larger zvl* imply all smaller zvl*. For example, zvl128b imply zvl64b, and zvl32b. Therefore, "-march=rv64iv -misa-spec=20191213" will be "rv64i2p0_f2p0_d2p0_v1p0_zicsr2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0". Note: zicsr is the imply extension of f. * For zve32x, the (segmant) load/store instructions are illegal when EEW is 64. Besides, vsew cannot be set to 64 by vsetvli when zve32* is enabled. * For zvl*b extensions, we also need to enable either v or zve* extensions. Otherwise we should issue errors. bfd/ * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules for v, zve* and zvl*b extensions. (riscv_supported_std_z_ext): Added zve* and zvl*b extensions. (riscv_parse_check_conflicts): The zvl*b extensions cannot be set without v and zve* extensions. gas/ * config/tc-riscv.c (riscv_extended_subset_supports): Handle zve*. (my_getVsetvliExpression): vsew cannot be set to 64 by vsetvli when zve32* is enabled. (riscv_ip): The (segmant) loads and stores with EEW 64 cannot be used when zve32x is enabled. * testsuite/gas/riscv/extended/march-imply-v.d: New testcase. * testsuite/gas/riscv/extended/march-imply-zve*.d: Likewise. * testsuite/gas/riscv/extended/march-imply-zvl*b.d: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zve32x.d: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zve32x.l: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zve32x.s: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zvl.d: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zvl.l: Likewise. * testsuite/gas/riscv/extended/vector-insns-fail-zvamo.d: Removed a-ext from -march since it will be added as implicit ext for zvamo. * testsuite/gas/riscv/extended/vector-insns.d: Likewise. include/ * opcode/riscv.h: Defined INSN_V_EEW64. opcodes/ * riscv-opc.c (riscv_draft_opcodes): Added INSN_V_EEW64 for vector loads and stores when the eew encodings are 64.

ilg-ul · 2021-11-15T18:56:27Z

Did anyone try to estimate the number of different combinations that require separate libraries in the embedded toolchain?

In the latest release, the xPack GNU RISC-V Embedded GCC supports roughly 100 libraries and the compressed archive has more than 500 MB.

kasanovic added a commit that referenced this issue Sep 16, 2021

Cleaned up segment load/store text.

8b874a8

Removed Zvlsseg extension name as segment load/stores are required in all standard vector extensions. Affects #723.

TommyMurphyTM1234 mentioned this issue Nov 15, 2021

Add non-C multi-libs xpack-dev-tools/riscv-none-embed-gcc-xpack#12

Closed

topperc mentioned this issue Sep 21, 2023

[RISCV] Fix wrong implication for zvknhb. llvm/llvm-project#66860

Merged

kito-cheng mentioned this issue Dec 27, 2023

[RISCV][MC] Add support for experimental Zcmop extension llvm/llvm-project#76395

Merged

This was referenced Aug 6, 2024

Use standard "depends upon" verbage rather than "requires" riscv/riscv-isa-manual#1583

Merged

[RISC-V] Inconsistent implied/required extension behavior for zabha/zvk* llvm/llvm-project#102249

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify the relationship between extensions. #723

Clarify the relationship between extensions. #723

kito-cheng commented Aug 26, 2021 •

edited

Loading

kito-cheng commented Aug 26, 2021

zakk0610 commented Sep 1, 2021

zakk0610 commented Sep 1, 2021

aswaterman commented Sep 1, 2021 •

edited

Loading

kito-cheng commented Sep 3, 2021 •

edited

Loading

Nelson1225 commented Sep 3, 2021

Nelson1225 commented Sep 3, 2021

jrtc27 commented Sep 5, 2021 •

edited

Loading

kito-cheng commented Sep 6, 2021

kito-cheng commented Sep 6, 2021

Nelson1225 commented Sep 7, 2021 •

edited

Loading

jim-wilson commented Sep 7, 2021

Hsiangkai commented Sep 8, 2021 •

edited

Loading

kito-cheng commented Sep 8, 2021

kito-cheng commented Sep 8, 2021

nick-knight commented Sep 8, 2021

kito-cheng commented Sep 8, 2021 •

edited

Loading

Hsiangkai commented Sep 9, 2021

zakk0610 commented Sep 9, 2021

nick-knight commented Sep 9, 2021 •

edited

Loading

kito-cheng commented Sep 9, 2021 •

edited

Loading

kito-cheng commented Sep 9, 2021

kito-cheng commented Sep 9, 2021

Hsiangkai commented Sep 16, 2021

Changes:

kasanovic commented Sep 18, 2021

aswaterman commented Oct 22, 2021 •

edited

Loading

ilg-ul commented Nov 15, 2021 •

edited

Loading

Clarify the relationship between extensions. #723

Clarify the relationship between extensions. #723

Comments

kito-cheng commented Aug 26, 2021 • edited Loading

kito-cheng commented Aug 26, 2021

zakk0610 commented Sep 1, 2021

zakk0610 commented Sep 1, 2021

aswaterman commented Sep 1, 2021 • edited Loading

kito-cheng commented Sep 3, 2021 • edited Loading

Changes: 2021/9/8: Update note for ELF attribute.

Nelson1225 commented Sep 3, 2021

Nelson1225 commented Sep 3, 2021

jrtc27 commented Sep 5, 2021 • edited Loading

kito-cheng commented Sep 6, 2021

kito-cheng commented Sep 6, 2021

Nelson1225 commented Sep 7, 2021 • edited Loading

jim-wilson commented Sep 7, 2021

Hsiangkai commented Sep 8, 2021 • edited Loading

kito-cheng commented Sep 8, 2021

kito-cheng commented Sep 8, 2021

nick-knight commented Sep 8, 2021

kito-cheng commented Sep 8, 2021 • edited Loading

Hsiangkai commented Sep 9, 2021

zakk0610 commented Sep 9, 2021

nick-knight commented Sep 9, 2021 • edited Loading

kito-cheng commented Sep 9, 2021 • edited Loading

kito-cheng commented Sep 9, 2021

kito-cheng commented Sep 9, 2021

Hsiangkai commented Sep 16, 2021

Changes:

kasanovic commented Sep 18, 2021

aswaterman commented Oct 22, 2021 • edited Loading

ilg-ul commented Nov 15, 2021 • edited Loading

kito-cheng commented Aug 26, 2021 •

edited

Loading

aswaterman commented Sep 1, 2021 •

edited

Loading

kito-cheng commented Sep 3, 2021 •

edited

Loading

Changes:
2021/9/8: Update note for ELF attribute.

jrtc27 commented Sep 5, 2021 •

edited

Loading

Nelson1225 commented Sep 7, 2021 •

edited

Loading

Hsiangkai commented Sep 8, 2021 •

edited

Loading

kito-cheng commented Sep 8, 2021 •

edited

Loading

nick-knight commented Sep 9, 2021 •

edited

Loading

kito-cheng commented Sep 9, 2021 •

edited

Loading

aswaterman commented Oct 22, 2021 •

edited

Loading

ilg-ul commented Nov 15, 2021 •

edited

Loading