Re: [lldb-dev] [RFC] OS awareness in LLDB

2019-04-09 Thread Alexander Polyakov via lldb-dev
Gentle ping.

On Wed, Apr 3, 2019 at 8:05 PM Alexander Polyakov 
wrote:

> Hi lldb-dev,
>
> Currently I'm working on an OS plug-in for multiple operating systems and
> architectures, during my work, I noted a few moments I want to discuss with
> the community.
>
> 1) Adding RegisterContext to SB API:
> if you want your OS plug-in to support multiple architectures you need
> to implement
> things like *get_register_info, get_register_data...* for each
> architecture.
> In my mind, we could do that using RegisterContext, for example:
> *get_register_info* could just call
> RegisterContext::GetRegisterContextAtIndex(idx), the number
> of registers could be obtained from
> RegisterContext::GetRegisterCount();
> *get_register_data *could return SBRegisterContext instead of just
> bytes, then the process of
> fetching the register values might look as: for each register
> SBRegisterContext::WriteRegister(reg_info, reg_value).
> Please correct me if I'm missing something.
>
> 2) New lldb-mi command: -info-os
> the gdb-mi documentation defines this command and there is a problem
> with it. To fully
> implement it, we should be able to get CPU ID a thread is running on,
> but lldb
> does not have an abstraction for CPU ID at all, so it becomes unreal
> at least for now.
> I'm going to partly implement this command for Zephyr (e.g. return
> some value to indicate
> that the CPU ID is undefined) and I want to know if the community is
> interested in implementing
> that command inside lldb-mi (at least in part).
>
> --
> Alexander
>


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


[lldb-dev] [Bug 41446] New: Architecture documentation on expressions is completely wrong

2019-04-09 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=41446

Bug ID: 41446
   Summary: Architecture documentation on expressions is
completely wrong
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: r...@ocallahan.org
CC: llvm-b...@lists.llvm.org

https://lldb.llvm.org/architecture/index.html#expression

> The DWARF expression parser has been heavily modified to support type 
> promotion, new opcodes needed for evaluating expressions with symbolic 
> variable references (expression local variables, program variables), and 
> other operators required by typical expressions such as assign, address of, 
> float/double/long double floating point values, casting, and more.

Looks like this used to be true, but hasn't been true for years.

> Once expressions have be compiled into an AST, we can then traverse this AST 
> and either generate a DWARF expression that contains simple opcodes that can 
> be quickly re-evaluated each time an expression needs to be evaluated, 

Looks like this doesn't happen. Instead LLIR is generated and then either
interpreted or JITed.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev