labath added inline comments.
================ Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:4707 + else + // The register info is incorrect, just clear it. + m_register_info.Clear(); ---------------- tatyana-krasnukha wrote: > 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. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55718/new/ https://reviews.llvm.org/D55718 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
