[lldb-dev] Linux issues where I am not getting breakpoints...
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Thu Apr 13 04:07:41 PDT 2017
While definitely not a prime example of StringRef usage, it is not strictly
a bug either. Future calls of getopt will modify the value of optarg, but
the actual string it points to (will have pointed to) remains unchanged as
that is just some member of the initial argv array.
That said, I have no objections to making that a regular string, as it will
avoid any doubts in the future.
pl
On 12 April 2017 at 23:43, Zachary Turner via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> On Wed, Apr 12, 2017 at 10:43 AM Greg Clayton via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
>> What I now believe is happening is lldb-server is exiting for some reason
>> and then the process just runs and still shows the output in LLDB because
>> we hooked up the STDIO. I see lldb-server exits with an exit code of 0, but
>> no command had been sent to terminate it. I will track that down.
>>
>> Also, log_channels in lldb-gdbserver.cpp is using a llvm::StringRef
>> incorrectly:
>>
>> case 'c': // Log Channels
>> if (optarg && optarg[0])
>> log_channels = StringRef(optarg);
>> break;
>>
>> Bad! This is exactly when we shouldn't be using llvm::StringRef. optarg
>> is a static variable and can change if there are any arguments after "-c
>> <args>".
>>
>
> Good catch, log_channels should definitely be a std::string here.
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170413/7e3bcdbc/attachment.html>
More information about the lldb-dev
mailing list