Add setting for breakpoint PC adjustment from remote stubs which don't back PC up.

[EwanCrawford]

Summary

Currently m_breakpoint_pc_offset is only set using the python target definition file. This variable adjusts the PC for a breakpoint hit when the remote stub, like gdbserver, hasn't backed up the PC.

The introduction of reading XML target definition files from the remote however means that the XML target def has priority over the python target definition. So in cases where the XML is provided, the python target def isn't used. In such a situation there is no way to provide the breakpoint PC offset.

This patch allows the breakpoint offset variable to set using a settting. An alternative however could be to prioritize the python target definition, over the XML target definition.

[clayborg]

This isn't a setting anyone should be setting. I would recommend extending your target.xml if you have control over it, or also loading the target definition file and only taking what you need from it.

[clayborg]

I wouldn't be opposed to prioritizing the target definition python file over the target.xml. Maybe we can do this:

1 - Use the target definition python file if one is specified
2 - If the target definition doesn't have any of the info from the target.xml (registers) then proceed to read the target.xml
3 - Fall back on the qRegisterInfo packets

[EwanCrawford]

Prioritizing the python target definition seems a cleaner solution.

[clayborg]

Looks good.

lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

ProcessGDBRemote::BuildDynamicRegisterInfo (bool force)
     // If so then lets update our setting so the user knows what the timeout is
     // and can see it.
     const uint32_t host_packet_timeout = m_gdb_comm.GetHostDefaultPacketTimeout();
     if (host_packet_timeout)
     {
         GetGlobalPluginProperties()->SetPacketTimeout(host_packet_timeout);
     }
 
+    // Register info search order: 
+    //     1 - Use the target definition python file if one is specified.
+    //     2 - If the target definition doesn't have any of the info from the target.xml (registers) then proceed to read the target.xml.
+    //     3 - Fall back on the qRegisterInfo packets.
+
+    FileSpec target_definition_fspec = GetGlobalPluginProperties()->GetTargetDefinitionFile ();
+    if (target_definition_fspec)
+    {
+        // See if we can get register definitions from a python file
+        if (ParsePythonTargetDefinition (target_definition_fspec))
+            return;
+    }
+
     if (GetGDBServerRegisterInfo ())
         return;
     
     char packet[128];
     uint32_t reg_offset = 0;
     uint32_t reg_num = 0;
     for (StringExtractorGDBRemote::ResponseType response_type = StringExtractorGDBRemote::eResponse;
          response_type == StringExtractorGDBRemote::eResponse; 
ProcessGDBRemote::BuildDynamicRegisterInfo (bool force)
     }
 
     if (m_register_info.GetNumRegisters() > 0)
     {
         m_register_info.Finalize(GetTarget().GetArchitecture());
         return;
     }
 
-    FileSpec target_definition_fspec = GetGlobalPluginProperties()->GetTargetDefinitionFile ();
-        
-    if (target_definition_fspec)
-    {
-        // See if we can get register definitions from a python file
-        if (ParsePythonTargetDefinition (target_definition_fspec))
-            return;
-    }
-
     // We didn't get anything if the accumulated reg_num is zero.  See if we are
     // debugging ARM and fill with a hard coded register set until we can get an
     // updated debugserver down on the devices.
     // On the other hand, if the accumulated reg_num is positive, see if we can
     // add composite registers to the existing primordial ones.
     bool from_scratch = (m_register_info.GetNumRegisters() == 0);
 
     const ArchSpec &target_arch = GetTarget().GetArchitecture();