Thank You @MaskRay.
Wed, Jun 12
Tue, Jun 11
@sfertile Sorry but I can't find commit 729111cf1824159bb4dd331cab8a829eab30313f or f49f58527a6d8147524d8d6f2eb1feb70f856292 in either llvm/llvm-project (git monorepo) or llvm-mirror/lld (git multirepo). Do you have the revision numbers, e.g. r362867 (or rL362867 rLLD362867; the latters give a clickable link on Phabricator)
Let me revert this change.
Sean, feel free to revert a change if it broke buildbots like this. You don't have to go through a pre-commit code review for a revert change that fixes buildbots.
Mon, Jun 10
@MaskRay You broke the PowerpC64 build bot, and have been asked by both the buildbot maintainer (@anil9) and me to fix it. As of this morning the bot is still failing dues to the same problem (http://lab.llvm.org:8011/builders/ppc64le-lld-multistage-test/builds/4263/steps/build-stage2-unified-tree/logs/stdio) Can you please address that before committing PPC64 changes like this. I don't understand why you would consider committing more PowerPC64 changes when the bot is in this state, rather then fixing it first.
Fri, Jun 7
@MaskRay Are you planning on pulling this? The buildbot is still red and there have been numerous Power related changes going in with no buildbot coverage.
Thu, Jun 6
Tue, Jun 4
Wed, May 29
Fri, May 24
Tue, May 21
Fri, May 17
May 16 2019
May 15 2019
May 14 2019
May 13 2019
May 10 2019
May 9 2019
The "simplest" number 0x2000000 works no worse than other numbers so I'll just use it.
May 8 2019
MaskRay, looks like many tests under lld/tests are using llvm-objdump, a grep for llvm-objdump on this folder returned >1000 entries.
If PPC is anything like Arm, I would be very surprised to see a lot of inter-section conditional branches,
May 7 2019
Adding MaskRay as a reviewer for their familiarity with the llvm tools.
Thanks for posting this @adalava.
May 3 2019
May 2 2019
Abandoning in favour of D60958.
Removed extra blank lines and added binaries into the diff.
Apr 30 2019
Fixed return types to match the type of field being accessed.
Apr 25 2019
Patch looks really good. I think you managed to explain the toc-indirection without getting to verbose which is something I've struggled with. I have a couple minor suggestions and I need to go over the test a bit more indepth but overall this looks good to me.
Apr 24 2019
Apr 23 2019
The format of the binaries included in the patch don't seem correct, they create empty files. As a result the corresponding test are failing.
Apr 22 2019
Apr 18 2019
- Addressed @hubert.reinterpretcast comments
- Added the compiler and source used to generate the object file used in the test.
- Added test coverage of long section names (ie names of length 8 that are not null terminated)
- removed the checkSize function as there were no longer any users.
Apr 16 2019
Apr 15 2019
Apr 3 2019
Mar 29 2019
Other the a few minor nit picks, this LGTM.
Mar 28 2019
Mar 27 2019
Mar 20 2019
Patch LGTM, but I think someone more familiar with compiler-rt cmake needs to be the one to accept it.
Mar 19 2019
My main question would be, how is this going to fit into MC and the rest of LLVM? We support 4(?) object file formats there now (ELF, COFF (pretty much assumes Windows), wasm, and MachO), and MC is not designed to be very extensible. Will Triple::isOSBinFormatCOFF return true for XCOFF, or will it be distinct?
Mar 18 2019
I've added a few reviewers who have committed to the other file formats recently since none of us have a lot of experience with this part of llvm.
Mar 8 2019
Mar 6 2019
Mar 4 2019
Overall patch LGTM. Thanks for adding this. I have one small question about the llvm-readobj test though. IIUC the python file is used to generate the output files for test/tools/llvm-readobj/reloc-types.test. Do we need to run the python script to get the updated relocs.obj.elf-ppc64 file and update the checks for the added relocations in reloc-types.test?
Feb 21 2019
Feb 15 2019
Feb 12 2019
Feb 6 2019
Feb 5 2019