Hello,
Yeah you are right Mikhail, thanks for pointing it out, I
must ask, is there any bug already logged for this issue ?
Ravi
On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi guys and thank you for the excellent community
Hello,
Pavel- my question is how do we solve it ? should Mikhail log a bug ?
for this issue
BR,
A Ravi Theja
On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally <
ravithejaw...@gmail.com> wrote:
> Hello,
>
> Yeah you are right Mikhail, thanks for pointing it out, I
> must
mbolContext.cpp
> Sendingsource/Symbol/TypeMap.cpp
> Transmitting file data ...
> Committed revision 253618.
>
>
> > On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> > Pave
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
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 th
t.
> >>>
> >>> Since a lot of instructions can be recorded this way, the function call
> >>> history can be quite useful for debugging and especially since it is a
> lot
> >>> faster to collect function traces this way.
> >>>
on packets only.
> In case
> > >>> of concerns about too much data being transferred, we can limit the
> number
> > >>> of entries we report because anyway the amount of data recorded is
> too big
> > >>> to present all at once so we would have to resort to something
ument to this
> >> > >>> perf_event_interface. The recorded instructions are then written
> to
> >> > >>> the
> >> > >>> memory region assigned. Now this is basically the raw information,
> >> > >>> which can
>
; >> > >> available (much better)?
>> >> >> > >>
>> >> >> > >> As Pavel said, how are you planning to present the information
>> to
>> >> >> > >> the
>> >> >> > >> user? Through
Yes, thanx for the clarification.
On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath wrote:
> On 4 February 2016 at 10:04, Ravitheja Addepally
> wrote:
> > Hello Pavel,
> > In the case of expression evaluation approach you
> mentioned
> > that:
> > 1. The data could be accessible onl
Hello,
I wanted to know if there is any existing API or a set of API's that
could be used to retrieve the load addresses of the Modules ? secondly Can
we obtain the dumps of the loaded Elf 's like in the remote case
transporting them from the target to the host ?
BR,
A Ravi Theja
__
abath wrote:
> Hi,
>
> could you give us a bit more background about what are you trying to
> do? It's hard to answer the question without knowing a bit more...
>
> On 8 March 2016 at 10:42, Ravitheja Addepally via lldb-dev
> wrote:
> > Hello,
> > I wante
Hello,
I wanted to know if the remote protocol of LLDB is state less or not
? When i say state I am referring to if LLDB remembers the current process
or thread being debugged (which would mean we dont need to specify that in
the client to server packets ) . I was looking at the
GDBRemoteComm
Thank you all for the information.
On Tue, Mar 29, 2016 at 7:25 PM, Greg Clayton wrote:
>
> > On Mar 29, 2016, at 2:57 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> > I wanted to know if the remote protocol o
Hello all,
I am currently working on enabling Intel (R) Processor Trace
collection for lldb. I have done some previous discussions in this mailing
list on this topic but just to summarize , the path we chose was to
implement raw trace collection in lldb and the trace will be decoded
o
Hello,
The SBFileSpec class of APIs can be used to read files on the local
file system right ? I want to know if it can be used for reading files on
the remote file system ? or do we need to use some other API ?
BR,
A Ravi Theja
___
lldb-dev mail
ns out we have made the wrong decision. I was
> > thinking of either a naming convention
> > (SBThread::StartTraceExperimental) or some annotation/comment on the
> > methods. When we are confident this design is good, we can remove the
> > promote the api into the "stabl
t;> >
> >> > Also, thinking about new APIs, should we have a way to mark an API as
> >> > incubating/experimental? Maybe it would be good to mark these new APIs
> >> > as experimental for a while, so we have an option of changing them in
> >> > the
; >> >> > SBProcess::TraceNewThreads(...)
> >> >> > or
> >> >> > SBProcess::TraceAllThreads(...)
> >> >> > with the assumption that "all" also includes newly created threads
> in
> >> >> > the futu
gt; >> >> > created threads - the process needs to be stopped first, so you
> >> >> >> > can
> >> >> >> > enable trace collection. There certainly are cases where this
> >> >> >> > could
> >> >&
Hello,
I am currently working on Bug 27687 (PrintStackTraces), so the reason
for the failure is the erroneous unwinding of the frames from the zeroth
frame. The error is not detected in AddOneMoreFrame, since it only checks
for 2 more frames, if it was checking more frames in AddOneMoreFrame,
Hello,
I posted this query a while ago, i still have no answers, I am
currently working on Bug 27687 (PrintStackTraces), so the reason for the
failure is the erroneous unwinding of the frames from the zeroth frame. The
error is not detected in AddOneMoreFrame, since it only checks for 2 more
;
> >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hello,
> >> I posted this query a while ago, i still have no answers, I am
> currently working on Bug 27687 (PrintStackTraces), so
e frames in the
> stack. I want to run both the unwinders and select the one that gives more
> number of frames.
> >
> > On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda
> wrote:
> >
> > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
> > >
> &
to tell the difference
> between a real valid stack unwind and random data giving lots of "frames".
> >
> > It sounds like the problem that needs fixing is to figure out why the
> assembly unwind is wrong for frame 0. What do you get for
> >
> > disass -a
&g
Hello,
Can we use GDB with lldb-server ? I see the vice-versa wroks i.e
LLDB with gdbserver. I did try using lldb-server with GDB but I got errors
(incompatible packet length). I was wondering if there is some special
tweaking needed for lldb-server to work with GDB ?
BR,
A Ravi Theja
Hello,
Debugging with gdbserver is supported by LLDB, but does it support
all the features that are present in the latest version of gdbserver ? If
not till what version of gdbserver does it support ? and are there any
future plans to support the latest gdbserver ?
Best Regards,
A Ravi The
> - with the proposed API, it is not possible to get a trace for
>> >> >> >> > newly
>> >> >> >> > created threads - the process needs to be stopped first, so you
>> >> >> >> > can
>> >>
Hello,
The lldb-server sends hard coded values like 0x78 etc in case of
error, so does the ProcessGDBRemote use these numbers anyway except for
just detecting error ? ( in my understanding it doesn't seem to use the
value of the number please correct me if i am wrong ). Is there some
special
Hello,
I was trying to get Code Coverage for LLDB with GCOV on Linux by
adding the corresponding flags in the CMake files, but I am facing problem
with lldb-server, which does not give seem to generate the gcda files. The
host side does generate the gcov files although. The lldb-server does
xt and
> cmake/modules/HandleLLVMOptions.cmake).
>
> Also, you may want to double-check that the gcda files are being written
> to the
> right directory.
>
> best,
> vedant
>
>
> > On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.ll
Hello all,
Currently the remote protocol in LLDB does not allow sending Error
Strings in response to remote packets, it only allows for "ENN" format
where N is a hex integer. In our current ongoing work, we would like to
have support for Sending Error Strings from lldb-server. I would like t
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > What's the specific use case that you're trying to support with error
> messages in the protocol? My initial thought on this is that it's not
> really the debug server's job to generate human-readable e
is always 1-to-1 with the error code?
>
> > On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello all,
> >Currently the remote protocol in LLDB does not allow sending
> Error Strings in r
Hello,
I would just like to add one more point to this discussion about
error strings being human readable or not, I guess the whole purpose
of having error strings, is to present them to human users right ? i mean a
use case of sending strings, that are not human readable won't be
required.
Hello,
I want to implement support for reading Performance measurement
information using the perf_event_open system calls. The motive is to add
support for Intel PT hardware feature, which is available through the
perf_event interface. I was thinking of implementing a new Wrapper like
Ptrace
36 matches
Mail list logo
