Radare2: Decouple debugging profiles from the code

[XVilka]

Currently radare2 hardcodes all debugging profiles for both native debugging and external debuggers plugins, like GDB or WinDBG. I suggest to define the file format, e.g. similar to the one we use for syscalls/Windows API and/or SDB. This way they can be changed separately from the code and on the fly when required.

The code should unify the debugging profiles for native debuggers, GDB/LLDB remote client, WinDbg remote client when possible.

[radare]

Debuging profile = register profile? If so. Its already like this

On 5 Feb 2020, at 07:23, Anton Kochkov [e-mail] wrote:


Currently radare2 hardcodes all debugging profiles for both native debugging and external debuggers plugins, like GDB or WinDBG. I suggest to define the file format, e.g. similar to the one we use for syscalls/Windows API and/or SDB. This way they can be changed separately from the code and on the fly when required.

The code should unify the debugging profiles for native debuggers, GDB/LLDB remote client, WinDbg remote client when possible.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[XVilka]

No:

• Native https://github.com/radareorg/radare2/tree/master/libr/debug/p/native/reg
• WinDbg https://github.com/radareorg/radare2/blob/master/shlr/windbg/profiles.h
• GDB:
  
  
  
  • https://github.com/radareorg/radare2/blob/master/shlr/gdb/src/arch.c
  
  
  • https://github.com/radareorg/radare2/blob/master/libr/debug/p/debug_gdb.c#L451
  
  

[radare]

use the drp command to save/ load this profile from a file. those are "hardcoded" because we don't want to load that from disk, but the format is plaintext and it's defined already from the very first day i did the RReg api

On 5 Feb 2020, at 08:33, Anton Kochkov [e-mail] wrote:

No:

Native https://github.com/radareorg/radare2/tree/master/libr/debug/p/native/reg https://github.com/radareorg/radare2/tree/master/libr/debug/p/native/reg
WinDbg https://github.com/radareorg/radare2/blob/master/shlr/windbg/profiles.h https://github.com/radareorg/radare2/blob/master/shlr/windbg/profiles.h
GDB:
https://github.com/radareorg/radare2/blob/master/shlr/gdb/src/arch.c https://github.com/radareorg/radare2/blob/master/shlr/gdb/src/arch.c
https://github.com/radareorg/radare2/blob/master/libr/debug/p/debug_gdb.c#L451 https://github.com/radareorg/radare2/blob/master/libr/debug/p/debug_gdb.c#L451
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/radareorg/radare2/issues/15928?email_source=notifications&email_token=AAG75FQTMYZA2RG6LLOATMDRBJTVFA5CNFSM4KQFSBU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK2NYTY#issuecomment-582278223, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG75FVKDBW6TGDC3PBMF4LRBJTVFANCNFSM4KQFSBUQ.

[XVilka]

As you might notice the format is different between native debuggers, GDB client and WinDbg client.
There are pieces that can't be changed on the fly yet.

[abcSup]

I just looked into this issues and here are what I found.

• WinDbg https://github.com/radareorg/radare2/blob/master/shlr/windbg/profiles.h

enum {
    E_ActiveProcessLinks, // EPROCESS
    E_UniqueProcessId,    // EPROCESS
    E_Peb,                // EPROCESS
    E_ImageFileName,      // EPROCESS
    E_VadRoot,            // EPROCESS
    E_ThreadListHead,     // EPROCESS
    P_DirectoryTableBase, // PCB
    P_ImageBaseAddress,   // PEB
    P_ProcessParameters,  // PEB
    R_ImagePathName,      // RTL_USER_PROCESS_PARAMETERS
    ET_Tcb,               // ETHREAD
    ET_ThreadListEntry,   // ETHREAD
    ET_Win32StartAddress, // ETHREAD
    ET_Cid,               // ETHREAD
    C_UniqueThread,       // CLIENT_ID
    O_Max,
};

typedef struct {
    int build;
    int sp;
    int bits;
    int flags;
    int f[O_Max];
} Profile;

Profile seems to contain only offsets of Windows kernel internal structure, unrelated to the register profile.

• GDB:
  
  
  
  • https://github.com/radareorg/radare2/blob/master/shlr/gdb/src/arch.c
  
  
  • https://github.com/radareorg/radare2/blob/master/libr/debug/p/debug_gdb.c#L451
  
  

arch.c seems to be the libgdbr's internal structure to locate each register. Refactoring it to make use of RReg API might complicate it (it is actually confusing now as well) since libgdbr is just the backend of the r_debug_plugin_gdb plugin.

libgdbr actually parses the gdb xml target description xml.c:gdbr_parse_target_xml, convert it into the same plaintext format, in order to pass it back in its plugin r_debug_plugin_gdb (debug_gdb.c:r_debug_gdb_reg_profile).

[XVilka]

@abcSup I never said it should be exactly the same as RegAPI, but adding the ability to define and store in the text files or something like that.
If you think that WinDbg profiles don't worth the trouble since less numerous than GDB ones - ignore that part then. Good job for digging inside the sources!

[abcSup]

@XVilka You are right. My fault that I did overthink about RReg and focused on refactoring them to RReg. So, it should be a more general approach to move every profile regardless of every type to its own header file like how https://github.com/radareorg/radare2/tree/master/libr/debug/p/native/reg does.