Needed for https://reviews.llvm.org/D62964
Sorry, I don't think this should be done, as these values are just range delimiters, not actually values that a symbol's type can be. If a symbol in that range is required, it should either be specified by the actual value required (e.g. just "11") or with a corresponding specific enumeration value, if available (e.g. STT_MYOS_TYPE).
I'm totally fine with not commit this. But it seems just a small convenience from a tooling perspective (no need for the semantics of the symbol type) when you need the value but not in an OS or processor specific way and STT_LOOS looks better than "10"?
I may have been a bit hasty rejecting this. My concern is that I have already seen instances in LLVM where people possibly not well-versed in ELF try to use these as actual types in testing and in tools consuming these values, which can lead to confusion or worse, bogus output (e.g. llvm-readelf claiming that a symbol's type is STT_LOOS). @grimar, do you have any thoughts?
I agree it doesn't make sense to print as a symbol value, although I wouldn't mind if obj2yaml could somehow print it as a comment, e.g.:
Type: 10 # STT_LOOS Type: 11 # STT_LOOS+1
Similar to the behavior seen in tools/llvm-readobj/elf-section-types.test of printing LOOS+0xF00
Yes, I think I agree. This is delimiters and not values intended to be used. We might want to improve error reporing (i.e. introduce a error to explain this is not just unknown values, but unsupported values).
Or at least add a comment explaining that we don't enumCase them intentionally to ScalarEnumerationTraits<ELFYAML::ELF_STT>::enumeration probably to avoid futher confusion.