tatyana-krasnukha marked an inline comment as not done. tatyana-krasnukha 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(); ---------------- labath wrote: > 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. I would move these lists of registers from an ABI to according Architecture plugin, as well as trap opcodes from the Platform (as Greg has mentioned above). But for now, I'm trying to introduce ARC target with the minimally invasive way for common code. 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
