LLVM-MI, that can be used in Eclipse, lives here [1] and it is still in
use. Although more people working on it would be definitely better
situation that it is at the moment :-)...
[1] https://github.com/lldb-tools/lldb-mi
*Zdenek Prikryl* | /CTO/ | +420 541 141 475 | www.codasip.com
On 11/10/20 10:01 PM, Jonas Devlieghere wrote:
On Nov 10, 2020, at 12:58 PM, Zdenek Prikryl wrote:
Hi all,
Just for the record, we have successfully implemented the wrapping of addr_t
into a class to support multiple address spaces. The info about address space
is stored in the ELF file,
Hi all,
Just for the record, we have successfully implemented the wrapping of
addr_t into a class to support multiple address spaces. The info about
address space is stored in the ELF file, so we get the info from ELF
parser and then pass it to the rest of the system. CLI/MI interface has
We're using it with Eclipse and Eclipse based product, so I'd like to
keep as well! :-)...
Zdenek
On 7/2/19 12:21 AM, Ted Woodward via lldb-dev wrote:
We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d
really like to keep it!
Ted
*From:* lldb-dev *On Behalf Of
*Jonas
Hi Pavel, Thomas,
Just a note that this topic is repeating now and then. It'd be nice to
have a concept at least. We can go with an additional argument, or
enhance addr_t, or enhance Address, or create a new type for it. So,
some sort of discussion that would clarify the concept a little bit
Hi Daniel, Sanimir,
This feature request is repeating every now and then :-). I think it's
very useful, but it's not that easy to implement.
Additional comments embedded.
--
Zdenek Prikryl
On 11/28/2018 07:01 PM, Sanimir Agovic via lldb-dev wrote:
Hi Daniel,
On Sat, Nov 24, 2018 at 9:34
to name the type of the "address" member of the struct, but pretty
much all of the apis that currently take addr_t, could that the new
struct
instead).
On Thu, 17 May 2018 at 12:01, Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
On 04/19/2018 08:22 PM, Jim Ingh
the struct, but pretty
much all of the apis that currently take addr_t, could that the new struct
instead).
On Thu, 17 May 2018 at 12:01, Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
On 04/19/2018 08:22 PM, Jim Ingham wrote:
On Apr 19, 2018, at 10:54 AM, Greg Clayton <
ote:
On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
Hi lldb developers,
I've been researching using lldb + gdbserver stub that is based on Harvard architecture with
multiple address spaces (one program, multiple data). The commonly adopted appr
Hi,
Is anybody familiar with (De)materializer in the expressions for
registers? I'm facing really weird behavior. I have big endian target
and if I do register read, I got the correct results (e.g. 0x11223344),
but if I do print , I got 0x44332211. It seems that the
EntityRegister swap bytes
Maybe Kalimba developers can help here. Kalimba has crazy memory map...:-)
--
Zdenek
On 04/19/2018 08:32 PM, Ted Woodward wrote:
Hexagon has a single address space, so we don't need to do anything like this.
When I worked on Motorola 56xxx DSPs we had memory spaces, but we didn't use
RSP. We
ote:
On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
Hi lldb developers,
I've been researching using lldb + gdbserver stub that is based on Harvard architecture with
multiple address spaces (one program, multiple data). The commonly adopted appr
Hi lldb developers,
I've been researching using lldb + gdbserver stub that is based on
Harvard architecture with multiple address spaces (one program, multiple
data). The commonly adopted approach is that everything is mapped to a
single "virtual" address space. The stub reads/writes from/to
13 matches
Mail list logo
