Adding a new architecture into LLDB

Hello everyone,

I am trying to add a new architecture into LLDB.
My architecture is a accelerator with its own ISA for which we have a LLVM backend (release 7.1).

I have started by creating a new NativeProcessProtocol for my architecture. So I have a lldb-server that run on a x86, but which takes care of process of my architecture. I have forced it to use my NativeProcessProtocol.
I have a issue with this method because as the lldb-server is compile to run on a x86, some part of the code think that it is managing x86 process.

Maybe I am going in the wrong direction to add such new architecture to LLDB, I would be happy to try any other suggestions.

If you are interested, you can have a look at my branch “dev/rjodin/lldb_dpu” in our forked repo of LLDB “https://github.com/upmem/lldb”. The branch is not clean, but it can help you understand what I did.

Thanks,

logo signature mail 50x50.png

Hello everyone,

I am trying to add a new architecture into LLDB.
My architecture is a accelerator with its own ISA for which we have a LLVM backend (release 7.1).

I have started by creating a new NativeProcessProtocol for my architecture. So I have a lldb-server that run on a x86, but which takes care of process of my architecture. I have forced it to use my NativeProcessProtocol.
I have a issue with this method because as the lldb-server is compile to run on a x86, some part of the code think that it is managing x86 process.

Maybe I am going in the wrong direction to add such new architecture to LLDB, I would be happy to try any other suggestions.

lldb-server is currently meant to build a native debugging GDB server that can be used with lldb. If you want to always build a cross build lldb-server for your architecture, you will want to add a new tool that gets built in the CMakeList.txt in the tools/lldb-server directory. You will need to build it into a different binary like “lldb-server-dpu”. I am not sure how much trouble you will run into doing this though as much of the lldb-server build assumes things match the current host.

Indeed, that’s exactly what I’ve done. I’ve got a “lldb-server-dpu”, and the only modification I made to have it working as expected is to have a second “liblldbHost.a” (“liblldbHostDpu.a”), with a single modification in “HostInfoBase::ComputeHostArchitectureSupport” (https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298)

Seems to work well for the moment.

Romaric

logo signature mail 50x50.png

When we added support for Linux running on Hexagon, we treated it like any other Linux. We added the correct register handling, and built it. The issues you’re facing we handled in the compiler/rootfs. We built a cross-compiler that ran on x86 Linux, targeting Hexagon Linux. We set up a rootfs with all of the relevant headers and libraries (MUSL for the C library), told cmake that we were targeting Hexagon, and let it fly.

Later on we set up a buildbot that built BusyBox, and had it build our native llvm tools as well. We can ssh into a board running Hexagon Linux, and run clang/lldb natively. It looks just like x86 Linux.

Ted

logo signature mail 50x50.png