summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/BinaryFormat/MachOTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Re-land: [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-031-0/+47
| | | | | | | | | | | | | | This re-lands r333797 with a fix for big endian systems. Original commit message: This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333854
* Revert "Re-land: [MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-011-47/+0
| | | | | | | | This reverts commit r333803. Still breaking on big endian. Will sort this out later. llvm-svn: 333805
* Re-land: [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-011-0/+47
| | | | | | | | | | | | | | This re-lands r333797 with a fix for big endian systems. Original commit message: This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333803
* Revert "[MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-011-43/+0
| | | | | | | | | | This reverts commit r333797. This patch is failing on BigEndian bots. I will fix and re-land: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/19505/ llvm-svn: 333799
* [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-011-0/+43
This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333797
OpenPOWER on IntegriCloud