clayborg added a comment.
There is a SymbolContext function sorts types based on the context contained in
a SymbolContext. Seems like we should do the same thing here? See
SymbolContext::SortTypeList().
https://reviews.llvm.org/D33083
___
lldb-com
clayborg added a comment.
In https://reviews.llvm.org/D33083#751836, @jingham wrote:
> Actually, I take that back. Why do you have to call FindGlobalDataSymbol
> twice? Shouldn't FindGlobalDataSymbol do that work for you. After all you
> passed in the module. It should itself prefer symbols
clayborg added a comment.
Bonus point for implementing a global symbol search that is aware of the above
rules and can stop after step 1 if there are matches, and after step 2 if there
are matches, etc.
https://reviews.llvm.org/D33083
___
lldb-com
clayborg added a comment.
So my question is: if we go the jTrace packet route, I would like to not use
GDB remote key/value pairs, and just go full JSON. You can make a new JSON dict
and pass all of the GDB remote key/value pairs inside and then you can add a
"jparams" key whose value is the JS
clayborg added a comment.
The searching code is indeed better and what we now want, but I question of
this code should live in ClangExpressionDeclMap::FindGlobalDataSymbol. A better
home for this might be in SymbolContext::FindGlobalDataSymbol? Then others can
use this functionality. Other clie
clayborg added a comment.
Yeah, we need to document exactly what this is doing: looking for the best
symbol as an expression parser would want it, preferring symbols from the
current module in the SymbolContext, and then looking everywhere. Errors if
multiple exist in current module, or in any
clayborg added inline comments.
Comment at:
packages/Python/lldbsuite/test/functionalities/ptr_refs-objc/Makefile:10
+
+include $(LEVEL)/Makefile.rules
labath wrote:
> This looks like a copy-paste error, as you have everything twice.
good catch
Repository:
r
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Just a few makefile changes where CFLAGS is being modified and this will be
good to go. Much better location for this. Sean, please keep an eye out for
this kind of thing in the
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Very nice.
https://reviews.llvm.org/D33083
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/li
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Close, some minor fixes.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3293
+ if (custom_params_sp) {
+if (custom
clayborg added a comment.
Add a test and fix the minor things as suggested and this will be good to go.
https://reviews.llvm.org/D33426
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-com
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very close and overall very nice, just a few implementation details to take
care of.
Comment at: include/lldb/API/SBStructuredData.h:20-28
+ enum Type {
+
clayborg added a comment.
Looks like we are down to just running clang format on the code so the R"(
strings don't go over 80 chars and this is good to go from me.
https://reviews.llvm.org/D32585
___
lldb-commits mailing list
lldb-commits@lists.llv
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
If all R"( strings are under 80 characters, this is good to go. If not, just
fix and submit, no extra review needed.
https://reviews.llvm.org/D32585
___
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
No need for the "StructuredDataType::" or "lldb::StructuredDataType::"
prefixes. Since we aren't using an enum class (it was before) and since all
enumerators start with "eStruct
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
We should probably store the stacks as lldb::addr_t values that are load
addresses for quicker comparisons and searches. Inlined code details things
more clearly.
clayborg added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1304
+ // Allocate the response buffer.
+ uint8_t *buffer = new (std::nothrow) uint8_t[byte_count];
+ if (buffer == nullptr)
labath wrote:
> Hey
clayborg added a comment.
Much cleaner. After seeing how we must construct a UniqueStack just so we can
search for it, an even cleaner solution would be to make unique_stacks into:
std::map
https://reviews.llvm.org/D33426
___
lldb-commits mailin
clayborg added a comment.
Clicked submit too early with last comments. After seeing how we previously
needed to create a temp UniqueStack just to do the lookup, and also how
UniqueStack make its thread index ID list mutable, a better solution is to use
a std::map as shown in the inlined comment
clayborg added a comment.
The other option for fixing the problem with showing the wrong variables in the
backtraces would be to make up a new frame-format string that is used for
uniqued stack frames and use that format when showing uniqued stack frames:
(lldb) settings show frame-format-uni
clayborg added a comment.
Zach made some comments via e-mail:
> Couple of things:
>
> 1. Unless you really really want iteration over this map to be in some
> deterministic order, better to use unordered_map. And if you do want it to
> be in some deterministic order, you should provide a comp
clayborg accepted this revision.
clayborg added a comment.
Looks like a good starting point. Thanks for the changes.
https://reviews.llvm.org/D33426
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
clayborg resigned from this revision.
clayborg added a comment.
I trust Pavel to review this since it is in the Linux native plugins mostly.
https://reviews.llvm.org/D33674
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Glad this is happening. Does this mean we won't see the "bad eh frame" warnings
anymore on linux? See inlined comments.
Comment at: include/lldb/Symbol/DWARFCa
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
If the CIEs can change per CIE,l then this patch is fine.
Comment at: include/lldb/Symbol/DWARFCallFrameInfo.h:38
DWARFCallFrameInfo(ObjectFile &objfile, lldb::Section
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Looks good.
https://reviews.llvm.org/D34681
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
clayborg added a comment.
I would think we would try to enable this using something like:
QEnableErrorStrings
And if the the server responds with "OK" then we know it is enabled. By default
the server should not enable any fancy features without being asked. We would
like lldb-server to stay c
clayborg added a comment.
So std::vector shouldn't be used in a public API. You should make a class that
wraps your objects. LLDB's public API has lldb::SBInstruction and
lldb::SBInstructionList as examples. std::vector on other systems compiles
differently for debug and release builds and thin
clayborg added a comment.
In https://reviews.llvm.org/D33035#799404, @abhishek.aggarwal wrote:
> In https://reviews.llvm.org/D33035#799058, @clayborg wrote:
>
> > So std::vector shouldn't be used in a public API. You should make a class
> > that wraps your objects. LLDB's public API has lldb::SB
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
See inlined comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3176
+ EnableErrorStringInPacket();
StreamGDBRemote
clayborg added inline comments.
Comment at: source/Utility/StringExtractorGDBRemote.cpp:467
+if (str_index != std::string::npos)
+ error_messg = m_packet.substr(++str_index);
+
clayborg wrote:
> hex encode
There is also a hex decode that will need to be
clayborg added a comment.
Much better on the API with Swig. Just a few inlined questions around
GetRawBytes.
Comment at: tools/intel-features/intel-pt/PTDecoder.h:54-55
+
+ // Get raw bytes of the instruction
+ const uint8_t *GetRawBytes() const;
+
In the py
clayborg added a comment.
Looks good. Just one question on why we register a packet handler.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp:32-35
+ RegisterPacketHandler(
+ StringExtractorGDBRemote::eServerPacketType_QEnableErrorStrings,
+
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Wait for an OK from Pavel as well.
https://reviews.llvm.org/D34945
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llv
clayborg added a comment.
A few inline fixes, but this looks great. Very close
Comment at: include/lldb/Core/ArchSpec.h:26-30
namespace lldb_private {
class Platform;
-}
-namespace lldb_private {
class Stream;
-}
-namespace lldb_private {
class StringList;
}
--
clayborg added a comment.
Note that if you put "Differential Revision: " followed by the URL for this:
Differential Revision: https://reviews.llvm.org/D34945
in your source control commit message it will automatically close this for you
and add the SVN revision number into this as a message.
clayborg added a comment.
Looks fine to me, lets make sure Pavel is OK with this. On MacOS socketpair is
also much faster. Please run the following command while stopped at a
breakpoint with and without your change:
(lldb) process plugin packet speed-test
It will send and receive packets usi
clayborg added a comment.
Ah yes, I thought there was something missing...
Repository:
rL LLVM
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
I think is saying we should just store the Architecture plug-in in the target
instead of in the process. It will also need to be cleared when the target arch
is changed.
https://reviews.llvm.org/D31172
___
lldb-commits ma
clayborg added a comment.
Added a suggestion to make Target::GetArchitecturePlugin lazy and to ask if the
arch is supported. Most of the time we will set this once and never need to
change it, even when we attach, change arch, etc. The new suggestion will allow
us to use the same arch plug-in w
clayborg added a comment.
In https://reviews.llvm.org/D31172#808105, @labath wrote:
> In https://reviews.llvm.org/D31172#808038, @clayborg wrote:
>
> > Added a suggestion to make Target::GetArchitecturePlugin lazy and to ask if
> > the arch is supported. Most of the time we will set this once an
clayborg accepted this revision.
clayborg added a comment.
Let Pavel try this and verify and this is good to go.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo
clayborg added a comment.
Any news on any speed changes? Please post the output of:
(lldb) process plugin packet speed-test
Both without and with this change. Nice to track any perf improvements
https://reviews.llvm.org/D33213
___
lldb-commits m
clayborg requested changes to this revision.
clayborg added a comment.
Before any changes are submitted, we assume you are getting a clean test suite
run.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
clayborg added a comment.
I am not sure how you expect to submit any patches then. Patches must be tested
prior to submission.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/m
clayborg requested changes to this revision.
clayborg added a comment.
So we should just make sure this works:
(lldb) target symbols add --shlib a.out debug_binaries/a.out
The --uuid option is there to help you match up without having to specify the
file path. If I am understanding correctly,
clayborg added a comment.
In https://reviews.llvm.org/D35607#815769, @labath wrote:
> In https://reviews.llvm.org/D35607#814982, @clayborg wrote:
>
> > So we should just make sure this works:
> >
> > (lldb) target symbols add --shlib a.out debug_binaries/a.out
> >
> >
> > The --uuid option is t
clayborg added a comment.
One other idea if we go with the UUID::Type solution: if we have UUIDs that are
different, we could ask the ObjectFile (ObjectFileELF) to see if it thinks the
files go together. Not sure if there is anything in the ELF file that would
allow us to do that. In Mach-O we
clayborg added a comment.
I am not sure how sensitive typemaps are to the names of the arguments? Maybe
we can just have you use different names and then the two typemaps won't
collide? You can also write some manual code to do the remapping without
typemaps.
Regardless of whether you are goin
clayborg added a comment.
Add a test for this and this will be good to go.
https://reviews.llvm.org/D35525
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Looks fine, just add an error that checks that when the --file options is used,
that only one argument (symbol file) is specified.
Comment at: source/Commands/
clayborg created this revision.
Herald added a subscriber: aprantl.
LLDB currently crashes when given .debug_types debug information which is
enabled with -fdebug-types when compiling. All complex types are also missing.
Seeing as LLDB crashes at worse, or debugs, but provides no type resolution
clayborg accepted this revision.
clayborg added a comment.
Looks like there already is a test case that was failing as Jim mentioned.
Accepting based on that.
https://reviews.llvm.org/D35740
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
clayborg added a comment.
We have been hitting this at Facebook for server apps that statically link the
entire world (libc, libc++, libstdc++, all other needed shared libraries) as
the debug info is too large unless -fdebug-types-section is used.
Comment at: source/Plugins/S
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Please init fd
Comment at: tools/lldb-server/lldb-gdbserver.cpp:388
bool reverse_connect = false;
+ int connection_fd;
This must be initi
clayborg added a comment.
The enum might need to be scoped outside the function or in a header file...
https://reviews.llvm.org/D35734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-comm
clayborg added a comment.
I believe a crash looks like:
#include
int main(int argc, const char **argv) {
typedef enum FooTag {
Bar,
Baz
} Foo;
Foo foo = Bar;
printf("foo = %i\n", foo);
return 0; // Break here and "frame variable"
}
The enum gets put into
clayborg added a comment.
In https://reviews.llvm.org/D35734#819193, @probinson wrote:
> In https://reviews.llvm.org/D35734#818778, @tberghammer wrote:
>
> > This section have been already removed from Dwarf5 so I agree that we
> > shouldn't spend too much time adding support for it.
>
>
> Compi
clayborg added a comment.
> Greg, are you with me checking this in?
Sure thing
https://reviews.llvm.org/D35607
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Two issues we need to resolve:
- I don't think AddressClass should have Absolute as a value. Absolute values
in symbol tables are just numbers, not necessarily addresses.
- This
clayborg added a comment.
In your log we see:
[10] .text PROGBITS bb80 bb80
00054380 AX 0 0 16
[30] .debug_arangesMIPS_DWARF 0006c24c
0560 0
clayborg added a comment.
(in the above log output .text has a valid address, but .debug_aranges doesn't.
We might need to cross correlate withe the program headers to tell if something
gets loaded (PT_LOAD) for a given file address. What does the output of:
(lldb) image dump sections
look l
clayborg added a comment.
Looking at an ELF file with DWARF, I see:
(lldb) image dump sections
Dumping sections for 1 modules.
Sections for
'/Volumes/android/aosp/out/target/product/generic/symbols/system/lib/libart.so'
(arm):
SectID Type File Address
clayborg added a comment.
So where did the other changes go where we use "--fd" for non Apple builds? Did
those changes get lost? They will be needed.
Are you able to run the test suite now?
https://reviews.llvm.org/D33213
___
lldb-commits mailing
clayborg accepted this revision.
clayborg added a comment.
I'm ok as long as Pavel is ok. Please wait for the OK from him as well.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
clayborg added a comment.
So the issue is with the ObjectFileELF when it makes its symbol table. It is
taking this symbols:
49686: bcf0 0 NOTYPE LOCAL DEFAULT 40 $debug_ranges627
And saying it is a code symbol. This symbols has a NOTYPE on it, not FUNC like
the main symbol. Fix t
clayborg added a comment.
maybe lldb::SymbolType::eSymbolTypeCompiler?
https://reviews.llvm.org/D35784
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
It would be nice to auto detect the names correctly?
Comment at: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp:389
+ struct __lldb_dlopen_result { void *image_ptr; const char
*error_str; } the_result;
+
clayborg accepted this revision.
clayborg added a comment.
Remove the outdated comment and we are good to go.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/ll
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
I was out on vacation, sorry for the delay. Looks good.
https://reviews.llvm.org/D36068
___
lldb-commits mailing list
lldb-commits@lists.llvm
clayborg added a comment.
I was out on a week long vacation, sorry for the delay. The main questions is:
should symbols with NOTYPE actually be included in any address lookups. I would
vote for no as how can 1 address resolve to more than one section. That doesn't
make sense to me. One address
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
I was out on vacation, sorry for the delay. Looks good.
https://reviews.llvm.org/D33035
___
lldb-commits mailing list
lldb-commits@lists.llvm
clayborg added a comment.
I think a better solution is to not give the symbol's address a valid section
in the first place. This would be done in ObjectFileELF.cpp when . It doesn't
seem like the section is valid because $debug_ranges627 shouldn't have an
address that matches something in .text
clayborg added a comment.
It would be a good idea to see what this $debug_ranges627 symbol actually is.
It seems like a stray linker symbol that wasn't stripped? It would be a good
idea to figure out what this symbol is so we can determine how to deal with it
correctly.
https://reviews.llvm.o
clayborg added a comment.
Might need to retitle again as well
https://reviews.llvm.org/D35784
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
So I looked at the instances of STT_NOTYPE in a few shared libraries on my
computer and they do seem to have valid addresses in them.
> there are two sections (.text and .debug_ranges) for the file address 0xbcf0.
I don't see that from the log. I cleaned up the output
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Glad this worked.
https://reviews.llvm.org/D35784
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Looks fine. Sorry for the delay.
https://reviews.llvm.org/D36046
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
clayborg added a comment.
We need a test for this to ensure we don't regress.
https://reviews.llvm.org/D36620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
Yes: lldbassert would be fine for that since those get compiled out during
release. Patch looks fine. If we already have a test that would trigger the new
"lldbassert" you will add, then no need for a special test for this, else we
need a test that triggers this.
Rep
clayborg added a comment.
This is sure to trigger things in the test suite. We will need to ensure a few
things:
- test suite runs cleanly in debug mode after the lldbassert is added
- without changes to CommandObjectRegister.cpp that the lldbassert is
triggered, and if not, add a test
https:
clayborg added a comment.
Can you explain the issue with an example?
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1644-1656
+// A *.dwo file itself can have DW_AT_GNU_dwo_name (but no
+// DW_AT_comp_dir) (clang 4.0 generates such DWOs)
clayborg added inline comments.
Comment at: tools/lldb-mi/MICmdCmdVar.cpp:525-526
+// Don't go down into pointers or references, to avoid a loop
+lldb::SBType valueType = member.GetType();
+if (!valueType.IsPointerType() && !valueType.IsReferenceType())
+ if (Exa
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.
Comment at: tools/lldb-mi/MICmdCmdVar.cpp:518-522
+// skip pointers and references to avoid infinite loop
+if (member.GetType().GetTypeFlags() &
+
clayborg added inline comments.
Comment at: tools/lldb-mi/MICmdCmdVar.cpp:522
+ continue;
+
+// Handle composite types (i.e. struct or arrays)
Or even cleaner:
```
bool CMICmdCmdVarUpdate::ExamineSBValueForChange(lldb::SBValue &vrwValue,
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Makes sense even though this can be quite expensive.
https://reviews.llvm.org/D37154
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
clayborg added a comment.
Thanks for the info. Does this seem like it is a compiler bug? Seems like there
should be a DW_AT_comp_dir if the DW_AT_GNU_dwo_name is relative? Is it written
in the DWO spec that if the DW_AT_comp_dir is empty then it is referring to
itself? I would rather not hack L
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Just add a more descriptive comment that states this exact issue more clearly
as I didn't understand the issue from the comment that is there now (the
comment that starts on line 1644).
clayborg added a comment.
Looks fine to me.
https://reviews.llvm.org/D37926
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added inline comments.
Comment at: source/Commands/CommandObjectTarget.cpp:2056-2058
+if (m_interpreter.WasInterrupted()) {
+ break;
+}
Remove braces
Comment at: source/Commands/CommandObjectTarget.
clayborg added a comment.
The multiple feature fix is fine.
As for the qfThreadInfo fix, do you not have control over the OpenOCD GDB
server? I would be nice to modify it to return something valid in response to
qfThreadInfo? If you don't control or have access to modify the OpenOCD GDB
server
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
As long as everyone agrees that no threads from qfThreadInfo means there is one
thread whose thread ID is 1 then this is ok.
Repository:
rL LLVM
https://reviews.llvm.org/D37934
clayborg accepted this revision.
clayborg added a comment.
This should be good to go. Watch the buildbots for failures.
https://reviews.llvm.org/D33213
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
clayborg added a comment.
The default return value of WillResume should be no error. Sorry for not
catching this. The core file Process subclasses will need to override this
manually.
Repository:
rL LLVM
https://reviews.llvm.org/D37651
___
lldb
clayborg added a comment.
If we get a response of "l" for the "qfThreadInfo", it might be worth trying to
send a "https://reviews.llvm.org/H1"; packet (select thread ID 1 for subsequent
continues and steps) to see if the server knows about thread 1 before
proceeding? This patch also broke other
clayborg added a comment.
I like the solution detailed above by tatyana-krasnukha
Repository:
rL LLVM
https://reviews.llvm.org/D37934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
clayborg added a comment.
I think Zach might be correct. If we already gathered the data, why not just
output it all? Lets answer this first before returning to which implementation
to use when parsing it up into lines and dumping it. Seems a shame to throw any
data away.
https://reviews.llvm
clayborg added a comment.
ok. Then back to the "can we use StringRef"? We might be able to check if the
second.data() is NULL? It might be NULL if the string doesn't end with a
newline. It it does, it might be empty but contain a pointer to the '\0' byte?
https://reviews.llvm.org/D37923
___
clayborg added a comment.
Looks fine.
https://reviews.llvm.org/D37651
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
We should have a test. The test would need to use pexpect or something similar.
If anyone has any pointer on how to make a test for this, please chime in. I
was thinking just a pexpect based test.
https://reviews.llvm.org/D37923
701 - 800 of 2732 matches
Mail list logo
