Re: [lldb-dev] Inquiry about .debug_frame

[Ravitheja Addepally via lldb-dev]

Yes sure.

On Wed, Nov 25, 2015 at 8:00 AM,  wrote:

> lldb should be able to read both. Can you file a bug please?
> On Tue, Nov 24, 2015 at 02:50:20PM +0100, Ravitheja Addepally via lldb-dev
> wrote:
> > Hello,
> >While compiling with clang for i386, I notice that the CFI
> > information is distributed between the .eh_frame section and the
> > .debug_frame section, meaning for some functions the CFI info is present
> in
> > the .debug_frame section whereas for some it is present in the .eh_frame.
> > Now looking at the lldb code,  I see that this information is only read
> > from the .eh_frame section and not from the .debug_frame section. My
> > questions are the following ->
> > 1) Is there something that I missing ? is the  information that I
> provided
> > in this email correct ?
> > 2) If it is correct, is this expected behavior ? I mean if the CFI info
> is
> > present in the .debug_frame then I think it should be read ? coz it maybe
> > useful in unwinding scenarios ?
> >
> >
> > BR,
> > A Ravi
>
> > ___
> > 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] [Bug 25632] New: LLDB does not use the .debug_frame section to read the CFI

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25632

Bug ID: 25632
   Summary: LLDB does not use the .debug_frame section to read the
CFI
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ravithejaw...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

LLDB does not use the .debug_frame section to read the CFI, this was observed
for clang compiler with 32 bit option on a 64 bit machine. The
DWARFCallFrameInfo class is instantiated with the .eh_frame section, although
sometimes some of the CFI info may also be present in .debug_frame. To
reproduce, compile any C application with clang for 32 bit on a 64 bit machine.

-- 
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

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

[Pavel Labath via lldb-dev]

There has been some discussion in , as
to what get's printed when, but I don't think any changes went in yet.
I wouldn't be opposed to bringing back the old behavior (or keeping
the current one, for that matter), but I feel that any change here
should consistent with whatever is the outcome of the mentioned
discussion.

pl

On 24 November 2015 at 21:09, Ted Woodward via lldb-dev
 wrote:
> I’ve been working on an old rev that we’d released on; now I’m much closer
> to ToT as we move towards our next major Hexagon release.
>
>
>
> Core dumps on the old rev would print out a listing/disassembly for each
> thread in the core dump. Now it doesn’t.
>
>
>
> ToT does this, on x86 Linux:
>
>
>
>>bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
>
> (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core
> "/usr2/tedwood/lldb_test/coredump/lincore"
>
> Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
>
> (lldb) thread list
>
> Process 0 stopped
>
> * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5,
> name = 'lincrash', stop reason = signal SIGSEGV
>
> (lldb)
>
>
>
> I can see the listing by going up and down the stack, but I’d like to see
> the listing on load. Is the no listing intended?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
> ___
> 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] [BUG] Many lookup failures

[Ramkumar Ramachandra via lldb-dev]

Hi,

Basic things are failing.

(lldb) p lhs
(CG::VarExpr *) $0 = 0x00010d445ca0
(lldb) p lhs->rootStmt()
(CG::ExprStmt *) $1 = 0x00010d446290
(lldb) p cg_pp_see_it(lhs->rootStmt())
(const char *) $2 = 0x00010d448020 "%A = $3;"
(lldb) p cg_pp_see_it(def->rootStmt())
error: no member named 'rootStmt' in 'CG::Node'
error: 1 errors parsing expression
(lldb) p cg_pp_see_it(def)
error: no matching function for call to 'cg_pp_see_it'
note: candidate function not viable: no known conversion from
'CG::Node *' to 'CG_Obj *' for 1st argument
error: 1 errors parsing expression

It's total junk; why can't it see the inheritance VarExpr -> Node ->
CG_Obj? The worst part is that rootStmt() is a function defined on
Node!

Ram
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

[Philippe Lavoie via lldb-dev]

Sorry for the delay, I revisited the issue today.

It is causing a problem for our architecture which does not support single 
instruction stepping. We emulate it with breakpoints and a processor exception 
on branch taken.

For example:

When we step over a line with a breakpoint, our flavor of StepOverRange inserts 
a breakpoint at the next likely instruction and enables processor branch 
exception. LLDB will queue StepOverRange and StepOverBreakpoint plans.

The problem occurs when we stop on the breakpoint inserted by StepOverRange. 
ThreadPlanStepOverBreakpoint::DoPlanExplainsStop will see the stop reason is 
eStopReasonBreakpoint and ignore the breakpoint. Then StepOverRange's 
DoPlanExplainsStop will claim it and ThreadPlanStepOverBreakpoint gets 
discarded and does not reinsert the original breakpoint.

Is there a way to make our scenario fit in the default thread plans?
Maybe check the breakpoint kind of all 'step' breakpoints and set the thread's 
StopReason to Trace?

-Philippe


From: jing...@apple.com [jing...@apple.com]
Sent: Monday, October 05, 2015 5:26 PM
To: Philippe Lavoie
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

That is intended behavior.  MischiefManaged is called when an stop propagates 
to that plan, and it needs to decide whether it is done or not.  That’s not 
what happens when somebody decides to discard the plan.  WillPop will get 
called if you need to do some cleanup when the plan gets popped.

Was this causing some problem?

Jim

On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:


I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed to 
being popped from the stack), MischiefManaged() is not called and the disabled 
breakpoint is not re-enabled.

Is this the intended behavior ?

-Philippe
___
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