Hi,
The current state of the world for build attribute testing is as follows,
- test/MC/ARM/directive-eabi_attribtues.s -- this file tests that, for a small subset of <Attribute, Value> pairs, attributes are successfully encoded / decoded into / from assembly and object files.
- test/tools/llvm-readobj/ARM/attributes.s -- this file tests that, for a smaller subset of <Attribute, Value> pairs, attributes are successfully encoded / decoded into / from object files.
- test/CodeGen/ARM/build-attributes.ll -- Tests that the build attributes are correctly emitted in default cases, and when various command line options are specified (CPU, target attributes, etc)
The test/tools/llvm-readobj/ARM/attributes.s is redundant given that it tests an equally small (though different) subset of build attributes that the test/MC/ARM/directive-eabi_attribtues.s test tests. For ABI conformance, we should be testing every <Attribute, Value> pair, where feasible.
The description fields of tags are not being tested in this patch whereas they were being tested in test/tools/llvm-readobj/ARM/attributes.s (the removed file). I don't think it is useful to test the hard-coded strings in tools/llvm-readobj/ARMAttributeParser.cpp. As an aside, the strings are occasionally cryptic abbreviations for the actual descriptions in the ABI document. If these descriptions are going to be tested, they should be the descriptions verbatim out of the document IMO, not arbitrary abbreviations. I think this would be best left as a separate patch however.
The attached patch contains 163 separate test files. It would have been cleaner to bundle all tests into a single file and use conditional compilation to test each <Attribute, Value> pair, but I was unable to find a way of doing this with the LLVM driver tools. This is required because if you try and encode the same build attribute with two or more different values in the same input file, the object file emitter ignores all but the last specified build attribute.
Thank you for your time,
Charlie.
What's doing the capitalisation here? It seems highly suspect (not mentioned in the ABI as far as I can tell, and gets into sticky locale questions).