summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2015-08-15 01:21:01 +0000
committerJason Molenda <jmolenda@apple.com>2015-08-15 01:21:01 +0000
commita18f7071c228af023ea6a4341192d99b138afed0 (patch)
treef6f28e19c07c1c272f1891920a45308d8446c9ce /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
parent5e4303dc1421f15b3c86cac1383c58d95e567b6b (diff)
downloadbcm5719-llvm-a18f7071c228af023ea6a4341192d99b138afed0.tar.gz
bcm5719-llvm-a18f7071c228af023ea6a4341192d99b138afed0.zip
A messy bit of cleanup: Move towards more descriptive names
for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
-rw-r--r--lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp10
1 files changed, 5 insertions, 5 deletions
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index d4d653d3533..16a966dba42 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -636,9 +636,9 @@ ProcessGDBRemote::BuildDynamicRegisterInfo (bool force)
{
set_name.SetCString(value.c_str());
}
- else if (name.compare("gcc") == 0)
+ else if (name.compare("gcc") == 0 || name.compare("ehframe") == 0)
{
- reg_info.kinds[eRegisterKindGCC] = StringConvert::ToUInt32(value.c_str(), LLDB_INVALID_REGNUM, 0);
+ reg_info.kinds[eRegisterKindEHFrame] = StringConvert::ToUInt32(value.c_str(), LLDB_INVALID_REGNUM, 0);
}
else if (name.compare("dwarf") == 0)
{
@@ -4285,7 +4285,7 @@ ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info, GDBRemot
const uint32_t regnum = StringConvert::ToUInt32(value.data(), LLDB_INVALID_REGNUM, 0);
if (regnum != LLDB_INVALID_REGNUM)
{
- reg_info.kinds[eRegisterKindGDB] = regnum;
+ reg_info.kinds[eRegisterKindStabs] = regnum;
reg_info.kinds[eRegisterKindLLDB] = regnum;
prev_reg_num = regnum;
}
@@ -4333,9 +4333,9 @@ ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info, GDBRemot
if (pos != target_info.reg_set_map.end())
set_name = pos->second.name;
}
- else if (name == "gcc_regnum")
+ else if (name == "gcc_regnum" || name == "ehframe_regnum")
{
- reg_info.kinds[eRegisterKindGCC] = StringConvert::ToUInt32(value.data(), LLDB_INVALID_REGNUM, 0);
+ reg_info.kinds[eRegisterKindEHFrame] = StringConvert::ToUInt32(value.data(), LLDB_INVALID_REGNUM, 0);
}
else if (name == "dwarf_regnum")
{
OpenPOWER on IntegriCloud