Hey Sean,
Yeah, it's a nice feature - even if it only works with basic types as
you noticed. I'll look to fix up the concerns you've identified. We're
working on a few other hexagon-related patches to put into review, so
I'll add this one to the list. We'll add you as a reviewer when it
happens - thanks!
Colin
On 31/03/2015 16:02, Sean Callanan wrote:
Colin,
looking at that patch, it looks like it has some great ideas!
I have a few concerns:
(a) it looks like it is not 64-bit clean, it assumes that everything
it works with is 4 bytes wide;
(b) it's got some assertions where I'd prefer proper error handling;
(c) it relies on the PrepareTrivialCall infrastructure which only
handles simple argument types; and
(d) while it tries hard to ensure that strings are exported into the
target's memory, it doesn't have any provisions for moving other data
that the expression allocated.
While I'd defer to Jim Ingham for comment on the thread plan aspect, I
think the interpreter side looks like it has potential. Also that
part might still apply. I'm fine with ironing out (c) and (d) in
tree, working with the LLVM folks to get better solutions, but (a) and
(b) and a style nit here and there would currently block integration
from my point of view. Hopefully you agree that those are the easy
bits to fix.
If you can resurrect this patch against recent ToT, I'm happy to be a
reviewer.
Sean
Sent from my iPad
On Mar 31, 2015, at 4:41 AM, Colin Riley <co...@codeplay.com
<mailto:co...@codeplay.com>> wrote:
Hi Bhushan
We ran into this problem whilst doing the Hexagon DSP support in LLDB.
This review was up (http://reviews.llvm.org/D4672) but is now stale
without reviewers. Basically we added the ability to the IR
interpreter to call functions on the target using a threadplan which
manipulated the stack and registers to call functions and capture any
return values, which works well on bare metal without ability to jit.
Maybe the patches can be of help to you. I doubt they would apply
cleanly now given the length of time since it was uploaded. It's a
valuable feature, but priorities on the list were elsewhere :)
Colin
On 31/03/2015 12:30, Bhushan Attarde wrote:
Hi,
We are debugging a baremetal application using LLDB which is
connected to a remote target (supporting GDB remote protocol).
We are able to execute expressions involving global and frame
variables such as:
(lldb) expr var+4
However, LLDB is unable to execute expressions involving function calls.
(lldb) expr (int) bar(1,2)
error: Can't run the expression locally: Interpreter doesn't handle
one of the expression's opcodes
Function bar is defined as int bar(int, int).
The expression execution_policy is set to eExecutionPolicyNever as
CanJIT() returns false for baremetal applications.
This is because JIT is disabled for static dynamic loader targets.
TheIRInterpreter::CanInterpret returns false as it fails to
interpret call instruction (call to 'bar' is not an intrinsic).
Could you please help us on this?
-Regards
Bhushan
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
--
- Colin Riley
Games Technology Director
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website:http://www.codeplay.com
Twitter:https://twitter.com/codeplaysoft
This email and any attachments may contain confidential and /or privileged
information and is for use by the addressee only. If you are not the intended
recipient, please notify Codeplay Software Ltd immediately and delete the
message from your computer. You may not copy or forward it,or use or disclose
its contents to any other person. Any views or other information in this
message which do not relate to our business are not authorized by Codeplay
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd
does not accept any responsibility for any changes made to this message after
it was sent. Please note that Codeplay Software Ltd does not accept any
liability or responsibility for viruses and it is your responsibility to scan
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
--
- Colin Riley
Games Technology Director
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft
This email and any attachments may contain confidential and /or privileged
information and is for use by the addressee only. If you are not the intended
recipient, please notify Codeplay Software Ltd immediately and delete the
message from your computer. You may not copy or forward it,or use or disclose
its contents to any other person. Any views or other information in this
message which do not relate to our business are not authorized by Codeplay
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd
does not accept any responsibility for any changes made to this message after
it was sent. Please note that Codeplay Software Ltd does not accept any
liability or responsibility for viruses and it is your responsibility to scan
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
