> On Nov 18, 2016, at 3:45 PM, Mehdi Amini wrote:
>
> Hi,
>
> I had to revert it, because it breaks building LLDB on MacOS.
>
> It turns out it would break any client that is including llvm-config.h but
> not linking to libLLVMSupport.
> So either:
>
> - we shouldn’t allow to include llvm-co
BTW, this exact same code seems to have been copied either to or from
OptionValueFileSpecList::SetValueFromString, as it appears to have the same
bug. Again, not sure how to see it fail in the debugger, but maybe someone
knows?
On Fri, Nov 18, 2016 at 1:07 PM Zachary Turner wrote:
> Also, I jus
On 11/18/16 3:55 PM, Zachary Turner via lldb-dev wrote:
On line 708 of CommandObjectFrame.cpp, I'm looking at this code:
options.SetRootValueObjectName(name_cstr);
This code occurs inside the else block of an if/else. name_cstr is
declared prior to the if/else block and initialized to nullptr
If you're not working in LLDB's Windows process plugin, you probably don't
care about this message.
FYI: I'm doing some refactoring (actually unfactoring) in the Windows
process plugin. It'll take a series patches over a few days next week. If
you're planning on working in this area, please let
On line 708 of CommandObjectFrame.cpp, I'm looking at this code:
options.SetRootValueObjectName(name_cstr);
This code occurs inside the else block of an if/else. name_cstr is
declared prior to the if/else block and initialized to nullptr, but is only
ever set to something other than nullptr in t
Hi,
I had to revert it, because it breaks building LLDB on MacOS.
It turns out it would break any client that is including llvm-config.h but not
linking to libLLVMSupport.
So either:
- we shouldn’t allow to include llvm-config.h without linking to LLVM, in which
case I need to look a bit close
Obviously a bug. Fixed in r287386.
Jim
> On Nov 18, 2016, at 11:47 AM, Zachary Turner via lldb-dev
> wrote:
>
> CommandObjectThreadUntil::DoExecute() has the following code:
>
> for (size_t i = 0; i < num_args; i++) {
> uint32_t line_number;
> line_number = String
Also, I just noticed the loop only runs one time, so it appears equivalent
to
m_path_mappings.Remove(remove_indexes.size() - 1, m_notify_changes);
which seems completely wrong
On Fri, Nov 18, 2016 at 1:05 PM Zachary Turner wrote:
> In the switch / case handler for eVarSetOperationRemove, there
In the switch / case handler for eVarSetOperationRemove, there is the
following code:
if (num_remove_indexes) {
// Sort and then erase in reverse so indexes are always valid
std::sort(remove_indexes.begin(), remove_indexes.end());
for (size_t j = num_remove_indexes -
CommandObjectThreadUntil::DoExecute() has the following code:
for (size_t i = 0; i < num_args; i++) {
uint32_t line_number;
line_number =
StringConvert::ToUInt32(command.GetArgumentAtIndex(0),
UINT32_MAX);
if (li
I'm seeing particular globals spuriously being reported as local variables:
they're returned by SBFrame::GetVariables(true, true, false, true) because
their scope is eValueTypeVariableLocal.
I've tracked down the problem but don't know DWARF well enough to determine
the right fix. Anyone want to h
11 matches
Mail list logo
