[lldb-dev] [Bug 33875] New: TestWithModuleDebugging fails since llvm r308708
https://bugs.llvm.org/show_bug.cgi?id=33875 Bug ID: 33875 Summary: TestWithModuleDebugging fails since llvm r308708 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org This commit added skeleton compile unit to the generated module. This extra compile unit confuses lldb's dwarf parsing logic, because it thinks this is a DWO compile unit. However, the rest of the module contains regular compile units. Since we have a DWO compile unit at offset zero, the DIE queries get forwarded to the compile units in the pch module, even though the regular dwarf behavior would be to first look up the compile unit based on the die offset alone, and then fetch the DIE from that unit. I'm not really sure what would be the best fix for this situation. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Pavel OOO
I will be on parental leave for the next ~three months. I will take a peek on the mailing lists from time to time, but my response times will be unpredictable, and I probably won't be in a position to help with troubleshooting any linux/android issues. For the time being, please direct your linux&android questions/problems/code reviews to Eugene and Tamas. I look forward to seeing you all on the llvm developers' meeting in October. cheers, pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Trying to use socketpair for lldb-server fails
The first thing I'd do is use the lldb logging mechanism. lldb-server closes its own stdout and stderr, because nobody is interested in output from the server, just from the target. Except when you're debugging the server, so there is an easy way to turn on logging. Set the following environment variables: LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs will be written to LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to turn logging on for. The format is "channel category:channel category...". If you want more than 1 category for a channel, I think "channel cat1 cat2..." works. This is not spelled out very clearly, unfortunately. Quickly glancing at the code, it looks like you need to implement a socketpair connection, and handling of the fd:// connection URL, starting in ConnectionFileDescriptor::Connect. The log for this would be "lldb connection". Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Demi > Obenour via lldb-dev > Sent: Wednesday, July 19, 2017 7:44 PM > To: lldb-dev@lists.llvm.org > Subject: [lldb-dev] Trying to use socketpair for lldb-server fails > > To avoid a local privilage escalation, I am trying to patch LLDB not to use a TCP > socket for local communication. > > The attached patch failed. Would anyone be able to provide suggestions for > how to debug the problem? > > Sincerely, > > Demi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Execution contexts in the OptionValue subsystem?
There's a function in OptionValueProperties
(http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
line 234):
const Property *OptionValueProperties::GetPropertyAtIndex(
const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx)
const {
return ProtectedGetPropertyAtIndex(idx);
}
Its callersgoto some trouble to collect and pass around the
ExecutionContext (e.g., GetSubValue passes it around everywhere,
GetPropertyAtrIndexAs* has to keep iteverywhere, theDump mechanism
passes around ExecutionContexts, etc.)
Aside from calling this function with completely ignores the
ExecutionContext, I don't see the execution contexts getting used
anywhere. Is this a remnant from old code?
Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Execution contexts in the OptionValue subsystem?
> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
> wrote:
>
> There's a function in OptionValueProperties
> (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
> line 234):
>
> const Property *OptionValueProperties::GetPropertyAtIndex(
> const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
> return ProtectedGetPropertyAtIndex(idx);
> }
>
> Its callers go to some trouble to collect and pass around the
> ExecutionContext (e.g., GetSubValue passes it around everywhere,
> GetPropertyAtrIndexAs* has to keep it everywhere, the Dump mechanism passes
> around ExecutionContexts, etc.)
>
> Aside from calling this function with completely ignores the
> ExecutionContext, I don't see the execution contexts getting used anywhere.
> Is this a remnant from old code?
For instance (from Process.cpp):
class ProcessOptionValueProperties : public OptionValueProperties {
public:
ProcessOptionValueProperties(const ConstString &name)
: OptionValueProperties(name) {}
// This constructor is used when creating ProcessOptionValueProperties when it
// is part of a new lldb_private::Process instance. It will copy all current
// global property values as needed
ProcessOptionValueProperties(ProcessProperties *global_properties)
: OptionValueProperties(*global_properties->GetValueProperties()) {}
const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
bool will_modify,
uint32_t idx) const override {
// When getting the value for a key from the process options, we will always
// try and grab the setting from the current process if there is one. Else
// we just
// use the one from this instance.
if (exe_ctx) {
Process *process = exe_ctx->GetProcessPtr();
if (process) {
ProcessOptionValueProperties *instance_properties =
static_cast(
process->GetValueProperties().get());
if (this != instance_properties)
return instance_properties->ProtectedGetPropertyAtIndex(idx);
}
}
return ProtectedGetPropertyAtIndex(idx);
}
};
That's what tells you whether to use the global process property, or this
process specific one. Ditto for Thread properties.
Jim
>
> Sean
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Execution contexts in the OptionValue subsystem?
Was this just curiosity, or was this getting in your way somehow?
Jim
> On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
>> wrote:
>>
>> There's a function in OptionValueProperties
>> (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
>> line 234):
>>
>> const Property *OptionValueProperties::GetPropertyAtIndex(
>>const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
>> return ProtectedGetPropertyAtIndex(idx);
>> }
>>
>> Its callers go to some trouble to collect and pass around the
>> ExecutionContext (e.g., GetSubValue passes it around everywhere,
>> GetPropertyAtrIndexAs* has to keep it everywhere, the Dump mechanism passes
>> around ExecutionContexts, etc.)
>>
>> Aside from calling this function with completely ignores the
>> ExecutionContext, I don't see the execution contexts getting used anywhere.
>> Is this a remnant from old code?
>
> For instance (from Process.cpp):
>
> class ProcessOptionValueProperties : public OptionValueProperties {
> public:
> ProcessOptionValueProperties(const ConstString &name)
> : OptionValueProperties(name) {}
>
> // This constructor is used when creating ProcessOptionValueProperties when
> it
> // is part of a new lldb_private::Process instance. It will copy all current
> // global property values as needed
> ProcessOptionValueProperties(ProcessProperties *global_properties)
> : OptionValueProperties(*global_properties->GetValueProperties()) {}
>
> const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
> bool will_modify,
> uint32_t idx) const override {
>// When getting the value for a key from the process options, we will
> always
>// try and grab the setting from the current process if there is one. Else
>// we just
>// use the one from this instance.
>if (exe_ctx) {
> Process *process = exe_ctx->GetProcessPtr();
> if (process) {
>ProcessOptionValueProperties *instance_properties =
>static_cast(
>process->GetValueProperties().get());
>if (this != instance_properties)
> return instance_properties->ProtectedGetPropertyAtIndex(idx);
> }
>}
>return ProtectedGetPropertyAtIndex(idx);
> }
> };
>
> That's what tells you whether to use the global process property, or this
> process specific one. Ditto for Thread properties.
>
> Jim
>
>
>>
>
>> Sean
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Execution contexts in the OptionValue subsystem?
I was evaluating whether to provide one in a target setting, and I
decidednot to.
Then I was looking to see why anyone wouild, and I couldn't find anyone
actually using it.
It's a little painful to see it passed around everywhere rather
thanstored by Process or Target, the two thingsthat care...but it's not
getting in the way of my work.
Sean
On 7/21/17 4:51 PM, Jim Ingham wrote:
Was this just curiosity, or was this getting in your way somehow?
Jim
On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
wrote:
On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
wrote:
There's a function in OptionValueProperties
(http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
line 234):
const Property *OptionValueProperties::GetPropertyAtIndex(
const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
return ProtectedGetPropertyAtIndex(idx);
}
Its callers go to some trouble to collect and pass around the ExecutionContext
(e.g., GetSubValue passes it around everywhere, GetPropertyAtrIndexAs* has to
keep it everywhere, the Dump mechanism passes around ExecutionContexts, etc.)
Aside from calling this function with completely ignores the ExecutionContext,
I don't see the execution contexts getting used anywhere. Is this a remnant
from old code?
For instance (from Process.cpp):
class ProcessOptionValueProperties : public OptionValueProperties {
public:
ProcessOptionValueProperties(const ConstString &name)
: OptionValueProperties(name) {}
// This constructor is used when creating ProcessOptionValueProperties when it
// is part of a new lldb_private::Process instance. It will copy all current
// global property values as needed
ProcessOptionValueProperties(ProcessProperties *global_properties)
: OptionValueProperties(*global_properties->GetValueProperties()) {}
const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
bool will_modify,
uint32_t idx) const override {
// When getting the value for a key from the process options, we will always
// try and grab the setting from the current process if there is one. Else
// we just
// use the one from this instance.
if (exe_ctx) {
Process *process = exe_ctx->GetProcessPtr();
if (process) {
ProcessOptionValueProperties *instance_properties =
static_cast(
process->GetValueProperties().get());
if (this != instance_properties)
return instance_properties->ProtectedGetPropertyAtIndex(idx);
}
}
return ProtectedGetPropertyAtIndex(idx);
}
};
That's what tells you whether to use the global process property, or this
process specific one. Ditto for Thread properties.
Jim
Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Execution contexts in the OptionValue subsystem?
> On Jul 21, 2017, at 4:55 PM, Sean Callanan wrote:
>
> I was evaluating whether to provide one in a target setting, and I decided
> not to.
>
> Then I was looking to see why anyone wouild, and I couldn't find anyone
> actually using it.
>
> It's a little painful to see it passed around everywhere rather than stored
> by Process or Target, the two things that care... but it's not getting in the
> way of my work.
Not sure what you mean by that. "settings set target.process.whatever
something" has to convey to the process property setter it calls down to what
the current process is - if any. That's not something you can store in the
process. The process property setter could check the "selected process" but
that would be racy, and not a good idea.
Maybe I'm missing something, however.
Jim
>
> Sean
> On 7/21/17 4:51 PM, Jim Ingham wrote:
>> Was this just curiosity, or was this getting in your way somehow?
>>
>> Jim
>>
>>
>>> On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
>>>
>>> wrote:
>>>
>>>
>>>
On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
wrote:
There's a function in OptionValueProperties (
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
line 234):
const Property *OptionValueProperties::GetPropertyAtIndex(
const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
return ProtectedGetPropertyAtIndex(idx);
}
Its callers go to some trouble to collect and pass around the
ExecutionContext (e.g., GetSubValue passes it around everywhere,
GetPropertyAtrIndexAs* has to keep it everywhere, the Dump mechanism
passes around ExecutionContexts, etc.)
Aside from calling this function with completely ignores the
ExecutionContext, I don't see the execution contexts getting used
anywhere. Is this a remnant from old code?
>>> For instance (from Process.cpp):
>>>
>>> class ProcessOptionValueProperties : public OptionValueProperties {
>>> public:
>>> ProcessOptionValueProperties(const ConstString &name)
>>> : OptionValueProperties(name) {}
>>>
>>> // This constructor is used when creating ProcessOptionValueProperties
>>> when it
>>> // is part of a new lldb_private::Process instance. It will copy all
>>> current
>>> // global property values as needed
>>> ProcessOptionValueProperties(ProcessProperties *global_properties)
>>> : OptionValueProperties(*global_properties->GetValueProperties()) {}
>>>
>>> const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
>>> bool will_modify,
>>> uint32_t idx) const override {
>>>// When getting the value for a key from the process options, we will
>>> always
>>>// try and grab the setting from the current process if there is one.
>>> Else
>>>// we just
>>>// use the one from this instance.
>>>if (exe_ctx) {
>>> Process *process = exe_ctx->GetProcessPtr();
>>> if (process) {
>>>ProcessOptionValueProperties *instance_properties =
>>>static_cast(
>>>process->GetValueProperties().get());
>>>if (this != instance_properties)
>>> return instance_properties->ProtectedGetPropertyAtIndex(idx);
>>> }
>>>}
>>>return ProtectedGetPropertyAtIndex(idx);
>>> }
>>> };
>>>
>>> That's what tells you whether to use the global process property, or this
>>> process specific one. Ditto for Thread properties.
>>>
>>> Jim
>>>
>>>
>>>
Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> ___
>>> lldb-dev mailing list
>>>
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Execution contexts in the OptionValue subsystem?
If you don't pass an exe_ctx to the Target property setter, it will always set
the global property. If that's what you want that's fine, but be aware that's
what you'll get...
Jim
> On Jul 21, 2017, at 5:00 PM, Jim Ingham wrote:
>
>
>> On Jul 21, 2017, at 4:55 PM, Sean Callanan wrote:
>>
>> I was evaluating whether to provide one in a target setting, and I decided
>> not to.
>>
>> Then I was looking to see why anyone wouild, and I couldn't find anyone
>> actually using it.
>>
>> It's a little painful to see it passed around everywhere rather than stored
>> by Process or Target, the two things that care... but it's not getting in
>> the way of my work.
>
> Not sure what you mean by that. "settings set target.process.whatever
> something" has to convey to the process property setter it calls down to what
> the current process is - if any. That's not something you can store in the
> process. The process property setter could check the "selected process" but
> that would be racy, and not a good idea.
>
> Maybe I'm missing something, however.
>
> Jim
>
>>
>> Sean
>> On 7/21/17 4:51 PM, Jim Ingham wrote:
>>> Was this just curiosity, or was this getting in your way somehow?
>>>
>>> Jim
>>>
>>>
On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev
wrote:
> On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev
>
> wrote:
>
> There's a function in OptionValueProperties (
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup
> line 234):
>
> const Property *OptionValueProperties::GetPropertyAtIndex(
> const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
> return ProtectedGetPropertyAtIndex(idx);
> }
>
> Its callers go to some trouble to collect and pass around the
> ExecutionContext (e.g., GetSubValue passes it around everywhere,
> GetPropertyAtrIndexAs* has to keep it everywhere, the Dump mechanism
> passes around ExecutionContexts, etc.)
>
> Aside from calling this function with completely ignores the
> ExecutionContext, I don't see the execution contexts getting used
> anywhere. Is this a remnant from old code?
>
For instance (from Process.cpp):
class ProcessOptionValueProperties : public OptionValueProperties {
public:
ProcessOptionValueProperties(const ConstString &name)
: OptionValueProperties(name) {}
// This constructor is used when creating ProcessOptionValueProperties
when it
// is part of a new lldb_private::Process instance. It will copy all
current
// global property values as needed
ProcessOptionValueProperties(ProcessProperties *global_properties)
: OptionValueProperties(*global_properties->GetValueProperties()) {}
const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
bool will_modify,
uint32_t idx) const override {
// When getting the value for a key from the process options, we will
always
// try and grab the setting from the current process if there is one.
Else
// we just
// use the one from this instance.
if (exe_ctx) {
Process *process = exe_ctx->GetProcessPtr();
if (process) {
ProcessOptionValueProperties *instance_properties =
static_cast(
process->GetValueProperties().get());
if (this != instance_properties)
return instance_properties->ProtectedGetPropertyAtIndex(idx);
}
}
return ProtectedGetPropertyAtIndex(idx);
}
};
That's what tells you whether to use the global process property, or this
process specific one. Ditto for Thread properties.
Jim
> Sean
> ___
> lldb-dev mailing list
>
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Trying to use socketpair for lldb-server fails
Sadly, that gives me nothing in the log file. Also, ConnectionFileDescriptor::Connect already seems to handle this case. Running strace on all child processes gives a “Operation not permitted” error from setsid(). That seems like the culprit, which is strange. Would you mind providing the value you used for LLDB_SERVER_LOG_CHANNELS? Demi On Fri, Jul 21, 2017 at 2:55 PM Ted Woodward wrote: > The first thing I'd do is use the lldb logging mechanism. lldb-server > closes > its own stdout and stderr, because nobody is interested in output from the > server, just from the target. Except when you're debugging the server, so > there is an easy way to turn on logging. > > Set the following environment variables: > LLDB_DEBUGSERVER_LOG_FILE - this contains the path to the file the logs > will > be written to > LLDB_SERVER_LOG_CHANNELS - this contains the channels and categories to > turn > logging on for. The format is "channel category:channel category...". If > you > want more than 1 category for a channel, I think "channel cat1 cat2..." > works. This is not spelled out very clearly, unfortunately. > > > Quickly glancing at the code, it looks like you need to implement a > socketpair connection, and handling of the fd:// connection URL, starting > in > ConnectionFileDescriptor::Connect. The log for this would be "lldb > connection". > > Ted > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Demi > > Obenour via lldb-dev > > Sent: Wednesday, July 19, 2017 7:44 PM > > To: lldb-dev@lists.llvm.org > > Subject: [lldb-dev] Trying to use socketpair for lldb-server fails > > > > To avoid a local privilage escalation, I am trying to patch LLDB not to > use a TCP > > socket for local communication. > > > > The attached patch failed. Would anyone be able to provide suggestions > for > > how to debug the problem? > > > > Sincerely, > > > > Demi > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] SBStructuredData inconsistencies
Hello, I was adding support for `SBStructuredData` to my Rust bindings for the LLDB API and noticed a couple of things. Since 5.0 isn't out yet and these are newer API additions, I was hoping there might still be time to fix this. `SBStructuredData::GetFloatValue` returns a `double`, but other things that return a `double` like `SBData` use "Double" in the name of the method: `GetDouble`. The `StructuredDataType` enumeration uses `-1` as the value for `Invalid`, but other enumerations typically use `0` or even the occasional `1`. I think that this enumeration is the only one that uses a `-1` within the LLDB public APIs. Could we rename the method to `GetDoubleValue`? And can we re-number the enumeration values? If so, I would like to get this in for the 5.0 release. I know that Vadim Macagon has been using SBStructuredData from Python and reported that the Python / SWIG interface for GetStringValue is awkward to use, but I haven't looked into this myself yet. Thanks, - Bruce ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
