[lldb-dev] Adding a new architecture into LLDB

Ted Woodward via lldb-dev lldb-dev at lists.llvm.org
Mon Jul 15 10:45:54 PDT 2019


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
From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of Romaric Jodin via lldb-dev
Sent: Monday, July 15, 2019 5:00 AM
To: Greg Clayton <clayborg at gmail.com>
Cc: LLDB <lldb-dev at lists.llvm.org>
Subject: [EXT] Re: [lldb-dev] Adding a new architecture into LLDB

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

On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton <clayborg at gmail.com<mailto:clayborg at gmail.com>> wrote:



On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev <lldb-dev at lists.llvm.org<mailto:lldb-dev at lists.llvm.org>> wrote:

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.


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,
--
Romaric JODIN
UPMEM
Software Engineer

<logo signature mail 50x50.png>
_______________________________________________
lldb-dev mailing list
lldb-dev at lists.llvm.org<mailto:lldb-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



--
Romaric JODIN
UPMEM
Software Engineer

[cid:image001.png at 01D53B0A.FB29CCB0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190715/1810a9a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1939 bytes
Desc: image001.png
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190715/1810a9a9/attachment-0001.png>


More information about the lldb-dev mailing list