[lldb-dev] [Bug 42284] Support SWIG 4.0

2019-06-18 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=42284

Jonas Devlieghere  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com

-- 
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


[lldb-dev] Adding a new architecture into LLDB

2019-06-18 Thread Romaric Jodin via lldb-dev
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,
-- 
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Disassembling issue

2019-06-18 Thread Romaric Jodin via lldb-dev
Hi Ted,

Indeed, my lldb-server was returning the x86 triple.
I have managed to return the good triple by "hacking" the function
"GDBRemoteCommunicationServerCommon::Handle_qHostInfo" to return my
"ArchSpec" instead of going through the "HostInfo::GetArchitecture()"
function.

I think my problem is more about how I added my architecture into lldb. I
will start a new thread about it.

Thank you Ted for the answers, it was very helpful.
Romaric

On Thu, Jun 13, 2019 at 6:38 PM Ted Woodward  wrote:

> Hi Romaric,
>
>
>
> The call to Disassembler::FindPlugin should have arch set to your triple.
> If m_options.arch is not set on the disassembly command line, it will get
> it from the target:
>
>
>
>   if (!m_options.arch.IsValid())
>
> m_options.arch = target->GetArchitecture();
>
>
>
>
>
> That leads me to wonder if your triple is set correctly after you do the
> run. What is the output from these commands, when you’re stopped?:
>
>
>
> target list
>
> platform status
>
>
>
> My guess is you’re connected to a remote gdb-server on a simulator for
> dpu, and it’s telling lldb that the triple is x86_64.x.x.
>
>
>
> If target list says the arch is dpu before the run, and x86_64 after the
> run, we should look at the RSP log. Before the run, type
>
> log enable -f  gdb-remote packets
>
>
>
> Attach the file to your next message.
>
>
>
> Ted
>
>
>
> *From:* Romaric Jodin 
> *Sent:* Thursday, June 13, 2019 1:16 AM
> *To:* Ted Woodward 
> *Cc:* LLDB 
> *Subject:* [EXT] Re: [lldb-dev] Disassembling issue
>
>
>
> Hi Ted,
>
>
>
> Thank you for the answer.
>
> I'm not sure I understand you well. It seems to me that my program call
> "Disassembler::FindPlugin" with the "m_options.arch" set to "x86_64". But
> my toolchain does not contain a LLVM supporting x86_64, so it feels normal
> to me that it is not able to create this disassembler. What is weird is
> that the first time I'm executing it, it managed to do so.
>
>
>
> I also have kind of the same issue with breakpoint. It's like if I'm
> missing the debug information after I do the "run" command:
>
>
>
> (lldb) file test
>
> Current executable set to 'test' (dpu).
>
> (lldb) b main
>
> Breakpoint 1: where = test`main + 24 at test.c:8, address = 0x8078
>
> (lldb) r
>
> Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test'
> (dpu)
>
> Process 21312 stopped
>
> * thread #1, name = 'DPUthread0', stop reason = Thread finished
>
> frame #0: 0x80c0
>
> (lldb) b main
>
> Breakpoint 2: no locations (pending).
>
> WARNING:  Unable to resolve breakpoint to any actual locations.
>
>
>
> When I'm doing the disassembly, I can manage to disassemble if I add the
> option with my architecture to the command line, but as you can see below,
> I also do not have the debug information that I had at the first
> disassembly:
>
>
>
> (lldb) file test
>
> Current executable set to 'test' (dpu).
>
> (lldb) dis -s 0x8000
>
> test`__bootstrap:
>
> test[0x8000] <+0>:  jnzid, 0x8020
>
> test[0x8008] <+8>:  move   r0, 0xff
>
> test[0x8010] <+16>: release r0, 0x0, nz, 0x8018
>
> test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
>
> (lldb) r
>
> Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test'
> (dpu)
>
> Process 21312 stopped
>
> * thread #1, name = 'DPUthread0', stop reason = Thread finished
>
> frame #0: 0x80a0
>
> (lldb) dis -s 0x8000
>
> error: Unable to find Disassembler plug-in for the 'x86_64' architecture.
>
> (lldb) dis -s 0x8000 -A dpu
>
> 0x8000: jnzid, 0x8020
>
> 0x8008: move   r0, 0xff
>
> 0x8010: release r0, 0x0, nz, 0x8018
>
> 0x8018: subr0, r0, 0x1, pl, 0x8010
>
>
>
> Any ideas about it?
>
> Thanks,
>
> Romaric
>
>
>
> On Wed, Jun 12, 2019 at 6:55 PM Ted Woodward  wrote:
>
> The error is coming from source/Commands/CommandObjectDisassemble.cpp .
> It’s not able to create the disassembler for your architecture. The call to
> Disassembler::FindPlugin fails.
>
> My guess is something in the call to MCDisasmInstance::Create in
> source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp is failing. Step
> through that and make sure everything there is working.
>
>
>
> Ted
>
>
>
> *From:* lldb-dev  *On Behalf Of *Romaric
> Jodin via lldb-dev
> *Sent:* Wednesday, June 12, 2019 8:23 AM
> *To:* lldb-dev@lists.llvm.org
> *Subject:* [EXT] [lldb-dev] Disassembling issue
>
>
>
> Hi everyone,
>
>
>
> I'm trying to have lldb being able to debug my architecture. It does it
> well after loading my elf. But then I run it, stop it in middle, try to
> disassemble and at that point it seems that I lost some information about
> my architecture. lldb tries to disassemble it for x86, which in not
> possible with my toolchain.
>
>
>
> Here is a log of what I am doing:
>
>
>
> (lldb) file test
>
> Current executable set to 'test' (dpu).
>
> (lldb) dis -s 0x8000
>
> test`__bootstrap:
>
> test[0x8000] <+0>:  jnzid, 0x802