Author: davide
Date: Tue Dec 12 17:41:16 2017
New Revision: 320540
URL: http://llvm.org/viewvc/llvm-project?rev=320540&view=rev
Log:
[DataEncoder] Replace buggy versions of write functions.
This fixes a previously introduced thinko, now that I have
a better idea of what's going on :)
Modified:
Author: davide
Date: Tue Dec 12 17:41:17 2017
New Revision: 320541
URL: http://llvm.org/viewvc/llvm-project?rev=320541&view=rev
Log:
[IRExecutionUnit] Initialize uninititialized member variable.
Found by the ubsan build.
Modified:
lldb/trunk/include/lldb/Expression/IRExecutionUnit.h
Modif
Author: vedantk
Date: Tue Dec 12 12:19:40 2017
New Revision: 320522
URL: http://llvm.org/viewvc/llvm-project?rev=320522&view=rev
Log:
Add an #include to appease an older clang, NFC
Add in a missing #include that AppleClang-900 complains about when
building with -DLLVM_ENABLE_MODULES.
Modified:
clayborg added a comment.
No worries then. No need to make a new enum if this is just two places and they
aren't all setting the same flags.
https://reviews.llvm.org/D41070
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm
labath added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h:46
- //--
- /// Specify the program to launch and its arguments.
- ///
- /// @param[in] args
- //
labath added a comment.
In https://reviews.llvm.org/D40616#952432, @clayborg wrote:
> Does that sound right?
Yes, I'll get on it.
https://reviews.llvm.org/D40616
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-
clayborg added a comment.
Sounds good,. So the solution will be:
- Section::GetFileSize() will return the size in bytes of the section data as
it appears in the file
- Section::GetByteSize() will return the size in bytes for when this section is
loaded into process memory (we might consider ren
labath added a comment.
In https://reviews.llvm.org/D40616#951324, @clayborg wrote:
> I think GetFileSize() should remain the number of bytes of the section on
> disk and we should add new API if we need to figure out the decompressed
> size. Or maybe when we get bytes from a compressed section
