- User Since
- Apr 11 2019, 6:15 AM (41 w, 3 d)
It will require changing all possible initializations, with a sensible value.
Thu, Jan 23
Added ASCII output mode. It turns out that the unicode line drawing characters do work correctly on windows (at least windows 10, I don't have easy access to anything older to test with), I've left unicode as the default.
Mon, Jan 20
Why are you doing this in CodeGen, rather than adjusting the existing layout code in CGRecordLowering? Doing it this way will result in AdjustAAPCSBitfieldLValue being called for every access to the bitfield, rather than just once. This is probably more fragile too, because it's spreading the logic across multiple parts of the codebase, and has to undo some of the layout done by CGRecordLowering.
Fri, Jan 17
Thu, Jan 16
Thanks, our libc++ bots are passing now too: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2636
Tue, Jan 14
"The names are case insensitive for most targets, and usually written in lower case."
Mon, Jan 13
There are also some test failures (link errors caused by undefined references) on the ARM/AArch64 bots caused by this, so I'm going to revert it.
Thu, Jan 9
Wed, Jan 8
Mon, Jan 6
How does this interact with the AArch64 "branch-target-enforcement" attribute? For the generated, unpatched code to be correct the function needs to start with a BTI or PAC instruction if it could be indirectly called. Presumably the code doing the patching would also need to be aware of this.
Dec 12 2019
- Remove D70756 from patch
- Use -- style options in test comments
Sorry about that, I'd been marking comments as "done" as I went, but forgot to actually click "submit". I also accidentally included D70756 in the patch.
Dec 11 2019
- Made suggested changes to tests. I've enabled strict whitespace checking just for the one test in which we check compatibility with other options which affect the layout of the output, because the disassembly uses tabs in a way which doesn't always display well in text editors.
- getLocations now works correctly with -ffunction-sections, so removed the workaround
- Removed unused parameters related to DW_AT_frame_base
- Get endianness form the DWARFunit, no need to pass it around separately
- Don't create/destroy formatted_raw_ostream as often
Dec 10 2019
Dec 9 2019
Made the suggested changes in the code. However, after rebasing the DWARF5 tests are failing, as the location lists are being parsed incorrectly. I'll update the tests once I've figured out that's changed there.
Dec 6 2019
Dec 4 2019
- Use a switch statement in PrettyPrintDWARFOps
Dec 3 2019
Remove most DWARF opcodes except for simple registers, I'll add the rest back in later patches.
Dec 2 2019
This looks like multiple bug-fixes in one patch, could they be split up?
Is there a particular reason you've used ARM rather than x86 for these tests? A loose convention from my experience is that tests that require a target, but where the target doesn't actually matter, are written for X86.
Nov 29 2019
Now ready for review:
- Added tests, including a more complex expression emitted by GCC, and high register numbers needed for PPC.
- Print parentheses when needed by complex expressions, matching C operator precedence.
- Add command-line option to docs.
- Work correctly with -S and -l options (interleaved source code and line numbers), remove extra line number printing I added before I realised those options exist.
Nov 28 2019
Nov 27 2019
Not ready for review yet, but added DW_OP_regx and DW_OP_bregx needed for PPC.
Nov 26 2019
Nov 21 2019
Nov 20 2019
Nov 19 2019
Nov 14 2019
Nov 7 2019
Nov 6 2019
Nov 4 2019
LGTM with a few nits.
Nov 1 2019
I've reverted this (rGa3f474542) because it is causing failures when an instruction which modifies SP gets outlined. here's a reproducer:
Oct 30 2019
I'd like to see some more tests for this, in particular:
- Different combinations of register types being saved, e.g. only P regs without X or Z regs.
- Check that pairing of other register types still works in the presence of SVE callee-saved registers.
Oct 29 2019
Oct 28 2019
I think this also needs a check to make sure the selected architecture supports PAC/BTI. Gcc gives an unknown target attribute or pragma error if this is used for a non-AArch64 target.
Oct 21 2019
Oct 18 2019
So, if a, b and c participate in outlining, a and b have sign-return-address=all and c has sign-return-address=non-leaf, the new outlined function should behave like having sign-return-address=non-leaf? Or should we only allow outlining if the attributes match?
For testing, we have the SPACE pseudo-instruction, which can be used to emulate very large basic blocks, maybe you could reduce your reproducer using that?
How about -f[no-]force-dwarf-frame, which I think matches the spelling and behaviour of the existing -fforce-enable-int128 and -fforce-emit-vtables options?
Oct 17 2019
It looks like you're emitting PAC instructions but not AUT, so I'd expect this to fault when the outlined function returns. Or is some other code already returning using RETAA/RETAB? In which case, the test should check that.
I don't like the idea of adding a -gno-dwarf-frame option which doesn't always disable emission of .debug_frame. Since it doesn't make sense to emit other debug info without .debug_frame, maybe we should just not have a negative option?
Oct 11 2019
Oct 10 2019
Oct 9 2019
Oct 7 2019
Oct 3 2019
Oct 1 2019
Sep 23 2019
This makes the IR self-contained, which is good, but it also make the interpretation of the IR modal, which isn't great. It means that suddenly the rules of interpretation of what is valid to do or not changes according to this module flag.
Sep 20 2019
Sep 19 2019