Sure, fair enough.
If you have made a small repro case already though, it would be great
if you could file a bug about it, so we don't forget it.
pl
On 12 October 2015 at 23:23, Eugene Birukov wrote:
> I tried to repro it using standard LLDB client on a simple program that I
> could share. Well
Hi altogether,
I currently am developing an application where I need to access the
DWARF debugging information of my target process and its loaded .so files.
In more detail, I need to match type information of certain entities
within my code and its dynamically linked libraries.
I already
Hi,
well, I found the llvm-dwarfdump tool in the tools directory *facepalm*...
I'll use that as a reference.
That leaves the question about the two separate DWARF implementations.
Cheers,
Stefan
On 10/13/2015 11:42 AM, Stefan Kratochwil via lldb-dev wrote:
Hi altogether,
I currently am devel
Will do!
> From: lab...@google.com
> Date: Tue, 13 Oct 2015 09:40:28 +0100
> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing
> InferiorCallMmap
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org; jing...@apple.com
>
> Sure, fair enough.
>
> If you have made a smal
https://llvm.org/bugs/show_bug.cgi?id=25158
Todd Fiala changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|lldb-dev@lists.llvm.or
https://llvm.org/bugs/show_bug.cgi?id=25158
Bug ID: 25158
Summary: lldb fails to identify Linux OS for many shared
objects
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner wrote:
> Moving this to the public list because it seems useful to see what other
> members of the community have to say as well.
>
BTW , I realized I didn't give any context here and it's hard to follow a
long quote thread. Mostly this is just to
https://llvm.org/bugs/show_bug.cgi?id=25159
Bug ID: 25159
Summary: LLDB gets confused if evaluate expression executes
function that generates signal
Product: lldb
Version: 3.7
Hardware: PC
OS: Linux
Hi,
At one point in the debugging session, I get this when I try to print
a particular value:
error: field '__r_' declared with incompatible types in different
translation units
('std::__1::__compressed_pair, std::__1::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, s
> On Oct 13, 2015, at 9:03 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi,
>
> well, I found the llvm-dwarfdump tool in the tools directory *facepalm*...
> I'll use that as a reference.
>
> That leaves the question about the two separate DWARF implementations.
Ideally it would be good to
> On Oct 13, 2015, at 2:42 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi altogether,
>
> I currently am developing an application where I need to access the DWARF
> debugging information of my target process and its loaded .so files.
>
> In more detail, I need to match type information
In LLDB we create clang::ASTContext objects for the modules (executable and
shared libraries), one for the target to contain the expression results, and
one for each expression.
When we evaluate an expression we might do something like:
(lldb) expr a + b
where "a" is from liba.so and "b" is fr
I'm having a strange issue debugging a go program.
I set a breakpoint, and lldb stops at it. However, lldb thinks it's in a
different function:
(lldb) b wikilinktester.go:35
Breakpoint 1: where = wikilinktester`main.main + 805 at
wikilinktester.go:35, address = 0x2365
(lldb) r
Process
On Mon, Oct 12, 2015 at 7:31 PM, Zachary Turner wrote:
> Moving this to the public list because it seems useful to see what other
> members of the community have to say as well.
>
> On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner wrote:
>
>> It's worth also pointing out that if we go the route of
On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner wrote:
> On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner wrote:
>
>> Moving this to the public list because it seems useful to see what other
>> members of the community have to say as well.
>>
>
> BTW , I realized I didn't give any context here and
> Breakpoint 1: where = wikilinktester`main.main + 805 at
wikilinktester.go:35, address = 0x2365
The address of the breakpoint is kinda interesting - that seems
suspiciously low for an OS X user executable.
Which lldb are you using? If you built it, what process did you use to
build
16 matches
Mail list logo