Ok, that is one option, but one of the aim for this activity is to make the
data available for use by the IDE's like Android Studio or XCode or any
other that may want to display this information in its environment so
keeping that in consideration would the complete python based approach be
useful
On 29 January 2016 at 18:43, Jeffrey Tan wrote:
> Thanks Jim. Is this true for other platforms? Our IDE is going to support
> Mac and Linux and may extend to Windows some time later.
AFAIK, windows spawns a separate thread to do the actual debugging,
but this is hidden from you, and you can carry
On 30 January 2016 at 00:13, William Dillon wrote:
> In a very real sense, no information is lost here.
That is exactly the reason why it looks very hackish. :)
It looks to me like you are trying to work around some other bug,
probably in the code that consumes the triple.
Could you point me to
Hi,
it's a bit un-intuitive, but you should be able to create a target
with a null pointer for the executable, and use that to attach (see
CommandObjectProcessAttach::DoExecute).
BTW, if you find the existing API documentation too vague, we'd be
happy to accept any improvements.
cheers,
pl
On
It feels to me that the python based approach could run into a dead
end fairly quickly: a) you can only access the data when the target is
stopped; b) the self-tracing means that the evaluation of these
expressions would introduce noise in the data; c) overhead of all the
extra packets(?).
So, I w
And what about the ease of integration into a an IDE, I don't really know
if the python based approach would be usable or not in this context ?
On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath wrote:
> It feels to me that the python based approach could run into a dead
> end fairly quickly: a) you
Speaking for Android Studio, I think that we *could* use a
python-based implementation (hard to say exactly without knowing the
details of the implementation), but I believe a different
implementation could be *easier* to integrate. Plus, if the solution
integrates more closely with lldb, we could
If you want to go with the path to implement it outside LLDB then I would
suggest to implement it with an out of tree plugin written in C++. You can
use the SB API the same way as you can from python and additionally it have
a few advantages:
* You have a C/C++ API what makes it easy to integrate t
Great, thanks for the confirmation.
Sent from my iPhone
> On Feb 1, 2016, at 1:32 AM, Pavel Labath wrote:
>
>> On 29 January 2016 at 18:43, Jeffrey Tan wrote:
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support
>> Mac and Linux and may extend to Windows some time later
Often when attaching, you know the executable you are planning to attach to.
So the "normal" workflow is to create a target, then attach to the process with
that target's executable. This is particularly useful for remote debugging,
since having a local copy of the binary will mean less data l
https://llvm.org/bugs/show_bug.cgi?id=26421
Bug ID: 26421
Summary: CommandObjectRegister should set status
eReturnStatusSuccessFinishResult
Product: lldb
Version: 3.8
Hardware: All
OS: All
Status
Just a quick reminder: the early bird registration deadline for the
EuroLLVM 2016 is Feb 3rd.
Registration at: https://intranet.pacifico-meetings.com/GesCoForm/?cfg=887
More info about EuroLLVM 2016 at: http://llvm.org/devmtg/2016-03/
Kind regards,
--
Arnaud
_
Thanks guys, will give empty target a try.
On Mon, Feb 1, 2016 at 12:10 PM, Jim Ingham wrote:
> Often when attaching, you know the executable you are planning to attach
> to. So the "normal" workflow is to create a target, then attach to the
> process with that target's executable. This is par
(actually spelling lldb-dev correctly, sorry for the typo)
We'll be at Tied House as usual, starting on Thursday the 4th at 7pm!
If you can, help us plan and RSVP here: http://meetu.ps/2RN2C5
See everyone there!
-Chandler
___
lldb-dev mailing list
lldb
14 matches
Mail list logo
