[lldb-dev] Identifying instructions that definitely access memory

[Vangelis Tsiatsianas via lldb-dev]

Hello,

I am looking for a way to identify loads, stores and any other kind of 
instruction that definitely perform memory access and extract the address 
operand(s), however I was not able to find a cross-architecture API. The 
closest I stumbled upon are "MCInstrDesc::mayLoad()" and 
"MCInstrDesc::mayStore()", but I understand that their results are just a hint, 
so I would then need to examine the instruction name or opcode in order to find 
out whether it’s actually a load or store and which operand(s) is (are) memory 
address(es) and also do so for each architecture separately, which I would 
really like to avoid.

Is there a way to identify such instructions either by examining them through 
the disassembler (e.g. "DoesLoad()" | "DoesStore()") before they execute or 
right after they perform any kind of memory access?

Thank you very much, in advance! 


― Vangelis


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

Re: [lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

On Fri, Oct 18, 2019 at 10:17 AM Greg Clayton  wrote:

> Yeah this is a tough tradeoff as this is what GDB does or at least did the
> last time I was working on it. In most debuggers, they make up their own
> internal type representation, and have a generic LALR recursive descent
> parser to evaluate single expression statements. This parser must work for
> multiple languages and problems arise when one language has a keyword or
> special operator that others don't have. In the old days, if you wanted to
> call a C++ function in the GDB expression parser you would need to put
> quotes around any qualified names that contained : characters because that
> had been overloaded by the expression parser before C++ to allow getting to
> a static variable in a file ("g_foo:main.c" or "main.c:g_foo"), So you had
> to type '"foo::bar"()' in your expression. The type system tries to avoid
> these issues by allowing each language to define the best functionality for
> each language.
>

Going a bit on a tangent here, but it isn't obvious that a debugger
expression evaluator needs to match full syntax and capabilities of the
source language.  I've been able to get quite a bit of mileage out of a
Python "expression evaluator" on top of a wrapper similar to lldb.value
.  Not
optimal by any stretch, but quite acceptable for baseline experience, IMO.


> One idea is to add rust support in its own TypeSystem and require a cmake
> option to manually enable its compilation. If the cmake flag isn't
> supplied, Rust is not compiled in by default. That way you can upstream it,
> people can try to enable it if any only if they download the rust compiler
> sources. Might be nice to have a rust compiler revision or hash that people
> can/should checkout that is documented in the checked out LLDB sources in
> the Rust type system README. This revision would be the last known good
> revision of the Rust compiler sources they should download in order to
> build the version of Rust that is in LLDB's sources. This way it would not
> break if we had a script in the Rust LLDB sources that knew how to checkout
> the right version of Rust and then users can manually enable Rust. Any rust
> enabled buildbots could ensure the right Rust sources are checked out.
> Maybe you could integrate this with the LLVM mono repo where Rust could be
> a module that can be added so when you add the
> '-DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb;rust"' flag, it would know to
> build the rust bits needed for LLDB?
>

The Rust plugin is written in C++, so Rust compiler source won't be
necessary.  However a binary compiler release would be needed for testing.
It it certainly possible to make Rust support conditional on a cmake flag,
but would it be getting enough (or any) testing if not enabled by default?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev