Details
- Reviewers
jhenderson rupprecht MaskRay grimar labath - Commits
- rGc22d9666fc3e: [yaml2obj] Move core yaml2obj code into lib and include for use in unit tests
rL368119: [yaml2obj] Move core yaml2obj code into lib and include for use in unit tests
rG3cfeaa4d2c17: [yaml2obj] Move core yaml2obj code into lib and include for use in unit tests
rL368021: [yaml2obj] Move core yaml2obj code into lib and include for use in unit tests
Diff Detail
Event Timeline
Thanks for taking this on. I look forward to being able to use this in lldb tests.
I'm not an owner here, but the main question I have is about the library-readiness of the code you're moving. I see it's doing things like spewing errors to stderr and even calling exit(), neither of which is a very nice thing to do for a library (even if it's just a "test" library). Do you have any plans for addressing that?
llvm/unittests/ObjectYAML/yaml2ObjectFileTest.cpp | ||
---|---|---|
31 | nit: ASSERT_THAT_EXPECTED (from Testing/Support/Error.h) will print the actual error message if this ever fails (instead of just a useless "false is not true"). |
Generally looks OK to me. Comments/questions are inlined.
llvm/lib/ObjectYAML/yaml2obj.cpp | ||
---|---|---|
32 | yaml2obj was a tool name. Should it still be printed? Also seems it should not refer to file anymore, should it be "failed to parte YAML input"? |
llvm/lib/ObjectYAML/yaml2wasm.cpp | ||
---|---|---|
655 | It is probably time to wrap these things in namespace llvm { namespace yaml { ... } } |
I suggested to Alex offline that he not try to do any more than the bare minimum to get this moved over. Certainly more work needs doing to it, but I think that can be done at a later point rather than upfront when moving it, given how useful it will be to have when working on the libObject code if nothing else.
llvm/include/llvm/ObjectYAML/yaml2obj.h | ||
---|---|---|
51 | Let's have this return an llvm::Error. I shouldn't massively increase the complexity of this code. | |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
1 | Looks like this CMake is missing any reference to the include files, which means they won't get auto-magically added to things like Visual Studio's projects. If you take a look at libObject's CMakeLists.txt, you'll find an example of what to do. | |
17–22 | My instinct is that we should rename these files to match the naming style of other files in this library. Open to other suggestions though. | |
llvm/lib/ObjectYAML/yaml2obj.cpp | ||
20–23 | We should avoid functions like this in the new library code. Better would be something that returned llvm::Error. In practice, you should probably just call createStringError at all its call sites and pass the resultant Error up the stack. | |
llvm/unittests/ObjectYAML/CMakeLists.txt | ||
9 | Looks like filenames usually start with an upper-case letter. Also, the filenames usually reflect the names of the file they are testing, in this case yaml2obj.cpp, so let's call this YAML2ObjTest.cpp. |
Changed return of convertYAML to Error. Changed name of files from yaml2X to XEmitter. Wrapped unexported functions in anonymous namespace. clang-format.
git clang-format does not understand moved files it turns out, so it formatted things that I didn't touch. I figure if this is going to happen it might as well be now, though. I can change this back though.
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | CMake doesn't fail when generating files so I haven't done anything horribly wrong. I assume this works but I don't know how to test if it did. | |
llvm/lib/ObjectYAML/yaml2wasm.cpp | ||
655 | I did this in all the files. Also I wrapped things in an anonymous namespace, is this ok? | |
llvm/tools/yaml2obj/yaml2obj.cpp | ||
45 | I think its more convenient to not have to specify the file type. I wonder what others have to say. |
llvm/unittests/ObjectYAML/yaml2ObjectFileTest.cpp | ||
---|---|---|
31 | Thanks! I've been doing this a lot great to know about this better way! |
I'd like have a function which takes a (yaml) string, and get raw bytes in return. So, that would be slightly less that what you're doing in the unit test here (as you're also re-parsing those bytes into an object file), but I am guessing you're going to need the re-parsing bits for the work you're doing anyway.
Also, due to how lldb's object parsers work, I'll need to save that stream of bytes into a file, but that is something that can be easily handled on the lldb side too.
As for object types, my main interest is ELF files, as we already have unit tests using those (by shelling out to yaml2obj). However, having COFF and MachO support would be nice too, and if it's available people might be inclined to use it. Minidump is interesting too, but I already have a mechanism for using that.
I don't know if that answers your question. If it doesn't, you'll have to ask me something more specific. :)
llvm/lib/ObjectYAML/yaml2wasm.cpp | ||
---|---|---|
655 | llvm policy http://llvm.org/docs/CodingStandards.html#anonymous-namespaces is to keep the anonymous namespaces as small as possible, preferring the static keyword instead. So, in this case, that would mean only the class definitions need to be wrapped in namespace{}. | |
llvm/tools/yaml2obj/yaml2obj.cpp | ||
45 | I'm pretty ambivalent. On one hand, it's nice to have the same interface as the command line tool, but on the other, in the test you should always know the object type, so appending that to the function name does not hurt. |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | I checked with equivalent code, and it did the job on my Windows machine. | |
llvm/lib/ObjectYAML/yaml2obj.cpp | ||
21 | Maybe mark this with TODO: Rather than an empty string, let's at least report something like "yaml2obj failed". | |
23 | You don't need the trailing return type, I'm pretty sure. | |
llvm/test/tools/yaml2obj/invalid-docnum.test | ||
23 ↗ | (On Diff #211876) | Nit: no new line at end of file. |
llvm/test/tools/yaml2obj/invalid-docnum.test | ||
---|---|---|
1 ↗ | (On Diff #211998) | This sentence is poor grammar. Probably something like "Test that an error is reported when a docnum is specified, which is greater than the number of YAML inputs in the file." |
llvm/tools/yaml2obj/yaml2coff.cpp | ||
34 | This struct should be in the anonymous namespace. | |
llvm/tools/yaml2obj/yaml2elf.cpp | ||
58 | You're closing the anonymous namespace here, but start one again about 3 lines later. Merge them together. | |
llvm/tools/yaml2obj/yaml2wasm.cpp | ||
25 | This class should be in the anonymous namespace. |
I think it's fine to clang format the whole thing (since git clang-format isn't smart enough), but ideally it'd be a separate patch that lands first, so that this just shows the changes required for moving directories
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | This fails in a -DBUILD_SHARED_LIBS=On cmake build; I think you need to add a dep on MC here (or add set(LLVM_LINK_COMPONENTS MC)) FAILED: lib/libLLVMObjectYAML.so.10svn ... ld.lld: error: undefined symbol: llvm::StringTableBuilder::StringTableBuilder(llvm::StringTableBuilder::Kind, unsigned int) >>> referenced by ELFEmitter.cpp:104 (/usr/local/google/home/rupprecht/src/llvm-project/llvm/lib/ObjectYAML/ELFEmitter.cpp:104) >>> lib/ObjectYAML/CMakeFiles/LLVMObjectYAML.dir/ELFEmitter.cpp.o:(llvm::yaml::yaml2elf(llvm::ELFYAML::Object&, llvm::raw_ostream&)) |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | I ended up having to add quite a few more libraries before it would link. Were you just getting the errors you showed here or more than this? |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | Oh, sorry, this was the wrong suggestion -- the link libraries are controlled by the other build system, LLVMBuild.txt (see http://llvm.org/docs/LLVMBuild.html). Can you undo the change here and add MC to LLVMBuild.txt? |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | Would this mean that we can also remove some entries from LLVM_LINK_COMPONENTS for the yaml2obj tool itself, now that it does not reference some of these libraries directly? |
llvm/lib/ObjectYAML/CMakeLists.txt | ||
---|---|---|
1 | Thank you @rupprecht that worked :) Oh yeah. Thanks @labath :) |
Sorry, this patch broke tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/15993, I reverted it in r368035.
I fixed those here rG9eee4254796df1a34a0452fa91e8ce4e38b6a5bb. Could you re-land or do I need to do it?
Let's have this return an llvm::Error. I shouldn't massively increase the complexity of this code.