- User Since
- Jun 4 2013, 6:02 AM (236 w, 1 d)
As there aren't any strong opinions objections to the present implementation (I haven't registered any, at least), and it solves an existing problem in lldb, could we land this soon-ish?
Mon, Dec 11
@davide: Any thoughts on .yaml as a test file suffix?
Fri, Dec 8
Darwin uses a kqueue-based implementation of this, so it definitely won't *break* anything, although I'd appreciate it if you can check whether the test passes there. My cursory reading of the kqueue man page makes me believe it should not be affected by this.
Thu, Dec 7
The change makes sense, we just need to make the check cleaner.
Wed, Dec 6
Thank you for fixing this on such a short notice.
Jim, could you have a quick look at this?
I think this breaks any non-trivial cross-compilation scenario.
Tue, Dec 5
I've added a MemoryBufferRef (which is what most APIs accept) constructor that
takes a WritableMemoryBuffer. Since MemoryBufferRef (as well as MemoryBuffer)
operates with StringRefs, but WritableMemoryBuffer uses
(Mutable)ArrayRef<uint8_t> (I think was done because there is no equivalent to
MutableStringRef and having MutableArrayRef+StringRef combo would be weird),
I've also added a WritableMemoryBuffer::getBufferAsStringRef().
Mon, Dec 4
If the "excuse" for not following llvm here is that these structs mirror apple headers, should we restrict these warnings only to the relevant files (e.g. everything in source/Plugins/Language/ObjC)?
Fri, Dec 1
Rebase on master and update the test.
Thu, Nov 30
There aren't that many lldb developers... I wouldn't be surprised if the number of them having access to a red-hat machine is 1 (you).
This rewrites the test in terms on the new lldb-test utility. It should be applied on top of D40636.
I feel this is reimplementing llvm-readobj, but maybe that's appropriate as we are reimplementing object file readers as well (my original patch wouldn't be necessary if we were using the llvm object library). Minor comments below, but I actually quite like this approach. It's also much less code than I expected this will need.
Wed, Nov 29
Looks good, thanks.
Tue, Nov 28
On 28 November 2017 at 06:12, Zachary Turner via lldb-commits <email@example.com> wrote:
yaml2core would be an excellent idea for a tool.
Mon, Nov 27
The thing to be aware of with this testing strategy is that you will probably be the only person who will be able to run these tests and verify dwz functionality. If you don't setup a buildbot testing this then other developers will never even know if they have broken any dwz functionality in the future. While end-to-end tests are great and we need them, I think it would be worthwhile to think about other testing strategies. These can range from checking in a couple of siple dwz files and making sure we can extract information from them (see unittests/SymbolFile/PDB for code that does something similar) to reimplementing/upstreaming the utilities necessary to build dwz files ourselves (I am not sure what the dwz tool does, but the eu-strip and sepdebugcrcfix tools sound like they would be fairly easy to implement on top of existing llvm libraries).
I am only commenting on the c++14 stuff. I think all of the things you need here are available to us already through various llvm utilities. See inline comments for details.
Fri, Nov 24
Thu, Nov 23
This is a slight deviation from the initial approach. What I've done here is
that I've kept the register set indices in an os-specific form. I've done this
because it enables the parsing code in ProcessElfCore to be
architecture-agnostic -- it can just deal with OS specifics, and can just shove
any note it does not recognise to the side. These will be then parsed in the
corresponding register contexts, which can only deal with architecture
specifics, and ignore OS details, as the translation of os-specific note types
is provided by a separate lookup table.
Adding David Blaikie as a reviewer, as suggested by Rafael.
remove unbuffered=true from the test
Wed, Nov 22
Remove the RequiresNullTerminator flag