I/O errors when connecting to ARM gdbserver

[msftsecurityteam]

Hi, I am running gdbserver built with gdb 7.5, and when trying to connect to a remote gdbserver on an ARM machine I get the following:

ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 43 ('+')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 103 ('g')
input_interrupt, count = 1 c = 35 ('#')
input_interrupt, count = 1 c = 54 ('6')
input_interrupt, count = 1 c = 55 ('7')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 103 ('g')
input_interrupt, count = 1 c = 35 ('#')
input_interrupt, count = 1 c = 54 ('6')
input_interrupt, count = 1 c = 55 ('7')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 118 ('v')
input_interrupt, count = 1 c = 67 ('C')
and this repeats on the gdbserver side.

Radare2 side shows:

[0x4041fd6c]> dcs
Running child until next syscall
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers

[radare]

paste the line you are using to connect to that gdb

On 11/18/2014 09:45 PM, msftsecurityteam wrote:

Hi, I am running gdbserver built with gdb 7.5, and when trying to
connect to a remote gdbserver on an ARM machine I get the following:

ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 43 ('+')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 103 ('g')
input_interrupt, count = 1 c = 35 ('#')
input_interrupt, count = 1 c = 54 ('6')
input_interrupt, count = 1 c = 55 ('7')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 103 ('g')
input_interrupt, count = 1 c = 35 ('#')
input_interrupt, count = 1 c = 54 ('6')
input_interrupt, count = 1 c = 55 ('7')
input_interrupt, count = 1 c = 36 ('$')
input_interrupt, count = 1 c = 118 ('v')
input_interrupt, count = 1 c = 67 ('C')
and this repeats on the gdbserver side.

Radare2 side shows:

[0x4041fd6c]> dcs
Running child until next syscall
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers

—
Reply to this email directly or view it on GitHub
#1700.

[condret]

is that arm-server vbam? if so, don't blame us for shitty vbam-code

[msftsecurityteam]

@radare: radare2 -a arm -b 32 -d -D gdb -e io.va=true gdb://10.0.0.21:31337

@condret: not sure what vbam is? I just build the gdbserver from source with the CodeSourcery / Linaro toolchain

[condret]

vbam is a gb/gba emulator that supports gdbserver in theory. but in reallity it does not work with r2 nor real gdb

[msftsecurityteam]

Ah, no. This is an actual embedded Linux/ARM box

[XVilka]

@msftsecurityteam Can you bisect that commit which broken this? Because that was working well after we fixed it after Hack.Lu. This commit should be ok bf3c739. See also this #1560

[radare]

Use the r2-v script that comes in radare2-regressions repository to compile and track multiple versions of r2 marking them as good and bad.

r2-v log |less
r2-v use hashofcommithere
...test...
r2-v bad
r2-v use anotherhash..
...test....
Etc.

Ill probably write a blog post about this

On 19 Nov 2014, at 12:30, Anton Kochkov notifications@github.com wrote:

@msftsecurityteam Can you bisect that commit which broken this? Because that was working well after we fixed it after Hack.Lu. This commit should be ok bf3c739. See also this #1560

—
Reply to this email directly or view it on GitHub.

[msftsecurityteam]

@XVilka: confirming that commit bf3c739 works

@radare: tried using the r2-v script (maybe im being a dumbass?) but im getting:

bf3c739 git clone
./r2-v: line 48: cd: radare2-bf3c739d: No such file or directory
bf3c739 make

[msftsecurityteam]

@XVilka: actually I am now getting the following errors:

[0x40455d6c]> dc
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
[0x40455d6c]> dc
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
[0x40455d6c]> dc
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
r_debug_reg: error reading registers
[0x40455d6c]>

gdbserver shows:

input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 52 ('4')
input_interrupt, count = 1 c = 48 ('0')
input_interrupt, count = 1 c = 52 ('4')
input_interrupt, count = 1 c = 53 ('5')

[radare]

use r2-v init first

i use that script by installing it (make install in r2r)

use r2-v good and r2-v bad.. while you have another terminal with r2-v
log|less (/ CUR) to make a dicotopic search to identify which commit
broke the thing.

thanks

On 11/19/2014 06:02 PM, msftsecurityteam wrote:

@XVilka https://github.com/XVilka: confirming that commit bf3c739
bf3c739
works

@radare https://github.com/radare: tried using the r2-v script
(maybe im being a dumbass?) but im getting:

bf3c739
bf3c739
git clone
./r2-v: line 48: cd: radare2-bf3c739d: No such file or directory
bf3c739
bf3c739
make

—
Reply to this email directly or view it on GitHub
#1700 (comment).

[XVilka]

@msftsecurityteam any luck with bisecting?

[msftsecurityteam]

@XVilka - im sorry I have taken so long to respond. Unfortunately I have started a new job and I don't have access to all of the ARM hardware I had before :-\ so I cannot test anymore

[radare]

The ARM backend is still not fully working, i have been doing some tests on my RPI and opened this issue, so we can keep tracking those errors here too: #1773

[XVilka]

Getting similar on qemu-arm:

r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported

r_reg_get_value: 32bit oob read 172
r_reg_get_value: 32bit oob read 172
[0x40014000]> q
Do you want to quit? (Y/n)
Do you want to kill the process? (Y/n)
Backend does not implements kill()
┌─[ xvilka@xxlaptop ] [20:04:56 ] ~/radare/hacklu/hacklu-demos/demo4_arm_boot 
└>./connect_r2.sh 
r_debug_select: 6 6
XWJSTEP TOFALSE
pid = 21467472 tid = 1
r_debug_select: 21467472 1
r_reg_get_value: 32bit oob read 172
r_reg_get_value: 32bit oob read 172
r_reg_get_value: 32bit oob read 172
r_reg_get_value: 32bit oob read 172
[0x40014000]> 

[crowell]

i see this on arm host, arm guest

[crowell]

amd64 debugger, arm debuggee

minishwoods ~ » radare2 -a arm -b 32 -d -D gdb -e io.va=true gdb://10.0.0.23:5555
r_debug_select: 6 6
XWJSTEP TOFALSE
pid = 15535616 tid = 1
r_debug_select: 15535616 1
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
 -- If you want to open the file in read-write mode, invoke r2 with '-w'
r_debug_gdb_reg_read: small buffer 176 vs 200
[0xb6fcfd60]> dc
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
[0xb6fcfd60]> 

[radare]

We already know that gdb backend is not working in all platforms, anyone is going to look at it, should I? This must be ready for the release

[radare]

Anyone wants to take care of this issue?

The complains about the reg profile is because the total size of the regs differs from the one taken from the backend. See drp for more info.

On 29 Apr 2015, at 03:48, Jeffrey Crowell notifications@github.com wrote:

amd64 debugger, arm debuggee

minishwoods ~ » radare2 -a arm -b 32 -d -D gdb -e io.va=true gdb://10.0.0.23:5555
r_debug_select: 6 6
XWJSTEP TOFALSE
pid = 15535616 tid = 1
r_debug_select: 15535616 1
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
-- If you want to open the file in read-write mode, invoke r2 with '-w'
r_debug_gdb_reg_read: small buffer 176 vs 200
[0xb6fcfd60]> dc
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
r_debug_gdb_reg_read: small buffer 176 vs 200
[0xb6fcfd60]>
—
Reply to this email directly or view it on GitHub.

[XVilka]

0x160000000]> drp
=pc     pc
=sp     sp
=a0     r0
=a1     r1
=a2     r2
=a3     r3
gpr     x0      .64     0       0
gpr     x1      .64     8       0
gpr     x2      .64     16      0
gpr     x3      .64     24      0
gpr     x4      .64     32      0
gpr     x5      .64     40      0
gpr     x6      .64     48      0
gpr     x7      .64     56      0
gpr     x8      .64     64      0
gpr     x9      .64     72      0
gpr     x10     .64     80      0
gpr     x11     .64     88      0
gpr     x12     .64     96      0
gpr     x13     .64     104     0
gpr     x14     .64     112     0
gpr     x15     .64     120     0
gpr     x16     .64     128     0
gpr     x17     .64     136     0
gpr     x18     .64     144     0
gpr     x19     .64     152     0
gpr     x20     .64     160     0
gpr     x21     .64     168     0
gpr     x22     .64     176     0
gpr     x23     .64     184     0
gpr     x24     .64     192     0
gpr     x25     .64     200     0
gpr     x26     .64     208     0
gpr     x27     .64     216     0
gpr     x28     .64     224     0
gpr     x29     .64     232     0
gpr     x30     .64     240     0
gpr     sp      .64     248     0
gpr     pc      .64     256     0
gpr     cpsr    .32     264     0

r_debug_gdb_reg_read: small buffer 268 vs 328
[0x160000000]> 

From real Android device

[radare]

yes the arm debugger no longer works for any platform right now, neither ios, android, native linux or gdb remote. Looks like all this stuff got broken after the w32 rewrite, im aware of this, and im looking for spare time to fix it.

On 09 Jul 2015, at 17:53, Anton Kochkov notifications@github.com wrote:

0x160000000]> drp
=pc pc
=sp sp
=a0 r0
=a1 r1
=a2 r2
=a3 r3
gpr x0 .64 0 0
gpr x1 .64 8 0
gpr x2 .64 16 0
gpr x3 .64 24 0
gpr x4 .64 32 0
gpr x5 .64 40 0
gpr x6 .64 48 0
gpr x7 .64 56 0
gpr x8 .64 64 0
gpr x9 .64 72 0
gpr x10 .64 80 0
gpr x11 .64 88 0
gpr x12 .64 96 0
gpr x13 .64 104 0
gpr x14 .64 112 0
gpr x15 .64 120 0
gpr x16 .64 128 0
gpr x17 .64 136 0
gpr x18 .64 144 0
gpr x19 .64 152 0
gpr x20 .64 160 0
gpr x21 .64 168 0
gpr x22 .64 176 0
gpr x23 .64 184 0
gpr x24 .64 192 0
gpr x25 .64 200 0
gpr x26 .64 208 0
gpr x27 .64 216 0
gpr x28 .64 224 0
gpr x29 .64 232 0
gpr x30 .64 240 0
gpr sp .64 248 0
gpr pc .64 256 0
gpr cpsr .32 264 0

r_debug_gdb_reg_read: small buffer 268 vs 328
[0x160000000]>
From real Android device

—
Reply to this email directly or view it on GitHub #1700 (comment).

[radare]

it is working now?

[1n598]

Not working for me.

radare2 1.1.0-git 13146 @ darwin-x86-64 git.1.0.2-202-gdb0f4da
commit: db0f4da build: 2016-12-05

PS: used different commands to connect to the gdbserver, both using -D gdb -d gdb://, added -b 32, and also -AA sometimes. None of them works.

The target is a Linux 127.0.0.1 3.4.112-g4905d43-mCU #14 PREEMPT Fri Oct 28 11:20:43 CEST 2016 armv5tejl GNU/Linux

[radare]

Cant reproduce :? tried with arm32 and arm64 on qemu and real hardware

$ r2 -a arm -b 32 -d gdb://host:port

the same goes for arm64 if -b 64 is used

[XVilka]

This is an old bug, situation can be different nowadays. Close it if you can't reproduce.

…

On Jan 29, 2017 7:52 PM, "radare" ***@***.***> wrote: Cant reproduce :? tried with arm32 and arm64 on qemu and real hardware $ r2 -a arm -b 32 -d gdb://host:port the same goes for arm64 if -b 64 is used — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#1700 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMZ_WBbkvPuMXC1TRbqFz7CJFMWMlhcks5rXLXVgaJpZM4C9WsG> .