[Lldb-commits] [PATCH] D55718: [ARC] Basic support in gdb-remote process plugin
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Thu Jan 17 08:07:23 PST 2019
labath added inline comments.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:4707
+ // The register info is incorrect, just clear it.
> clayborg wrote:
> > Is this a GDB server that you can modify? Or is the code fixed? Seems weird to ask for registers, and get something back that doesn't work, and then have to fix it up. Why even tell us the registers then?
> None of 3 gdb-servers we use provides us with "dwarf" field (including Ashling gdb-server and OpenOCD). It's not their business to be aware of DWARF.
> I'm going to hardcode necessary registers in SysVABI_arc, then AugmentRegisterInfoViaABI will solve the problem.
BTW, I was looking at how we generate unwind plans last week (I need that for breakpad symbols), and was surprised to see that we need a running target to generate any kind of an unwind plan. After some examination, it turned out that all we use from that target is the list of registers. This is suboptimal for two reasons:
- you cannot test even the most basic unwind functionality (like parsing eh_frame) without having a live process (or a faithful mock) somewhere
- perhaps more importantly: the unwind info that does get parsed is cached in the object file, which can be shared between multiple targets. So if another target tries to use that info, and this target's stub sends us different register numbers than the previous one, then it's unwinding will be all wrong.
Anyway, my point here is that I would be supportive of transitioning to a different source of dwarf register numbers than the remote stub.
CHANGES SINCE LAST ACTION
More information about the lldb-commits