This PR implements part 1 of yaml2obj for the GOFF Object File Format. It adds support for the header and end records. --------- Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
This patchs adds the necessary code for inspecting or creating offloading binaries using the standing `obj2yaml` and `yaml2obj` features in LLVM. Depends on D127774 Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D127776
This patch adds a the first bits of support for a yaml representation of dxcontainer files. Since the YAML representation's primary purpose is testing infrastructure, the yaml representation supports both verbose and a more friendly format by making computable sizes and offsets optional. If provided they are validated to be correct, otherwise they are computed on the fly during emission. As I expand the format I'll be able to make more size fields optional, and I will continue to make the format easier to work with. Depends on D124804 Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D124944
Summary: The patch implements the mapping of the Yaml information to XCOFF object file to enable the yaml2obj tool for XCOFF. Currently only 32-bit is supported. Reviewed By: jhenderson, shchenz Differential Revision: https://reviews.llvm.org/D95505
This teaches obj2yaml to dump valid regular (not thin) archives. This also teaches yaml2obj to recognize archives YAML descriptions, what allows to craft all different kinds of archives (valid and broken ones). Differential revision: https://reviews.llvm.org/D89949
yaml2obj might crash on invalid input when unable to parse the YAML. Recently a crash with a very similar nature was fixed for an empty files. This patch revisits the fix and does it in yaml::Input instead. It seems to be more correct way to handle such situation. With that crash for invalid inputs is also fixed now. Differential revision: https://reviews.llvm.org/D61059 llvm-svn: 359178
Summary: This patch adds the ability to read a yaml form of a minidump file and write it out as binary. Apart from the minidump header and the stream directory, only three basic stream kinds are supported: - Text: This kind is used for streams which contain textual data. This is typically the contents of a /proc file on linux (e.g. /proc/PID/maps). In this case, we just put the raw stream contents into the yaml. - SystemInfo: This stream contains various bits of information about the host system in binary form. We expose the data in a structured form. - Raw: This kind is used as a fallback when we don't have any special knowledge about the stream. In this case, we just print the stream contents in hex. For this code to be really useful, more stream kinds will need to be added (particularly for things like lists of memory regions and loaded modules). However, these can be added incrementally. Reviewers: jhenderson, zturner, clayborg, aprantl Subscribers: mgorny, lemo, llvm-commits, lldb-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59482 llvm-svn: 356753
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
llvm-svn: 306925
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787