[yaml2obj][ELF] Suport STT_LOOS, STT_HIOS, STT_LOPROC and STT_HIPROC.

[ychen]

Summary

Needed for https://reviews.llvm.org/D62964

[jhenderson]

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).

[ychen]

In D63394#1545670, @jhenderson wrote:

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"?

[jhenderson]

In D63394#1546292, @ychen wrote:

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?

[ychen]

In D63394#1546401, @jhenderson wrote:

In D63394#1546292, @ychen wrote:

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?

Oh, that makes perfect sense to me.

[rupprecht]

In D63394#1546401, @jhenderson wrote:

In D63394#1546292, @ychen wrote:

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

[grimar]

In D63394#1546401, @jhenderson wrote:

In D63394#1546292, @ychen wrote:

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?

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.

llvm/lib/ObjectYAML/ELFYAML.cpp

#define ECase(X) IO.enumCase(Value, #X, ELF::X)
   ECase(STT_NOTYPE);
   ECase(STT_OBJECT);
   ECase(STT_FUNC);
   ECase(STT_SECTION);
   ECase(STT_FILE);
   ECase(STT_COMMON);
   ECase(STT_TLS);
   ECase(STT_GNU_IFUNC);
+  ECase(STT_LOOS);
+  ECase(STT_HIOS);
+  ECase(STT_LOPROC);
+  ECase(STT_HIPROC);
 #undef ECase
   IO.enumFallback<Hex8>(Value);
 }
 
 void ScalarEnumerationTraits<ELFYAML::ELF_STV>::enumeration(
     IO &IO, ELFYAML::ELF_STV &Value) {
 #define ECase(X) IO.enumCase(Value, #X, ELF::X)
   ECase(STV_DEFAULT);