r2 0.10.2 on fresh install of raspbian

[diouziou]

Hi

I encounter a bug when debugging the usual hello_world.c program on a fresh install of raspbian on a raspberry pi 3. When debugging with r2 -d:

• dc will work, but
• setting a breakpoint with db, and then using dc yields: signal 4 aka SIGILL received 0

I tried the suggestion by maijin: e dbg.swstep = true, but it still yields the same SIGILL

(rmk: i checked that gdb works fine on the same code)

All the best

[radare]

Swstep have nothing to do with breakpoints or continues. So obvioysly that fixes nothing. I have no rpi3 to test this. Iirc its arm64, right?

The sigill happens in the address of the breakpoint? Because then its just an issue of selecting a wrong breakpoint bytes.. Which is not really a problem but something to improve and it can be fixed in 1 line.

Pls confirm

On 11 Apr 2016, at 15:11, diouziou [email protected] wrote:

Hi

I encounter a bug when debugging the usual hello_world.c program on a fresh install of raspbian on a raspberry pi 3. When debugging with r2 -d:

dc will work, but
setting a breakpoint with db, and then using dc yields: signal 4 aka SIGILL received 0
I tried the suggestion by maijin: e dbg.swstep = true, but it still yields the same SIGILL

(rmk: i checked that gdb works fine on the same code)

All the best

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

[crowell]

rpi3 is aarch64?
On Apr 11, 2016 9:12 AM, "diouziou" [email protected] wrote:

Hi

I encounter a bug when debugging the usual hello_world.c program on a
fresh install of raspbian on a raspberry pi 3. When debugging with r2 -d:

• dc will work, but
• setting a breakpoint with db, and then using dc yields: signal 4 aka
  SIGILL received 0

I tried the suggestion by maijin: e dbg.swstep = true, but it still yields
the same SIGILL

(rmk: i checked that gdb works fine on the same code)

All the best

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

[diouziou]

1. yes it is arm64, but raspbian is 32 bits
2. yes, the sigill happens at the address of the breakpoint

[diouziou]

Here is the binary (with a .jpg extension)

[diouziou]

Some more comments: using aaa and aaaa give some bugs too (same hello world code). Here is a copy paste of what i get:

[0x76f26d40]> aaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[Cannot determine xref search boundariesr references (aar)
[x] Analyze len bytes of instructions for references (aar)
[Oops invalid rangen calls (aac)
[x] Analyze function calls (aac)
[*] Use -AA or aaaa to perform additional experimental analysis.
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[0x76f26d40]> aaaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[Oops invalid rangen calls (aac)
[x] Analyze function calls (aac)
[x] Emulate code to find computed references (aae)
[>] Scanning -r-x 0x76f26000 - 0x76f46000 done
Analyzed 0 functions based on preludes
[x] Finding function by preludes (aap)
[Cannot find section boundaries in here
[x] Analyze consecutive function (aat)
[hello world!alue pointers (aav)
Segmentation fault

sometimes the last two lines are the previous ones, sometimes :

[Segmentation faultointers (aav)
hello world!

and these two lines are printed in orange, as other lines starting with [

[diouziou]

Here is a debugging with gdb:

(gdb) run -d ./hello
Starting program: /usr/bin/r2 -d ./hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Process with PID 26307 started...
attach 26307 26307
bin.baddr 0x00010000
Assuming filepath ./hello
asm.bits 32
 -- I love gradients.
[0x76fcfd40]> aaaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[Oops invalid rangen calls (aac)
[x] Analyze function calls (aac)
[x] Emulate code to find computed references (aae)
[>] Scanning -r-x 0x76fcf000 - 0x76fef000 done
Analyzed 0 functions based on preludes
[x] Finding function by preludes (aap)
[Cannot find section boundaries in here
[x] Analyze consecutive function (aat)
[ ] Analyze value pointers (aav)
Program received signal SIGSEGV, Segmentation fault.
0x76ec4dd8 in cmd_anal_aav (core=0x54ac0ec8 <r>, input=0x54be8592 "v") at cmd_anal.c:3705
3705        ut64 from = s->vaddr;

and the backtrace after this:

(gdb) bt
#0  0x76ec4dd8 in cmd_anal_aav (core=0x54ac0ec8 <r>, input=0x54be8592 "v") at cmd_anal.c:3705
#1  0x76ec5208 in cmd_anal_all (core=0x54ac0ec8 <r>, input=0x54be8592 "v") at cmd_anal.c:3756
#2  0x76ec6330 in cmd_anal (data=0x54ac0ec8 <r>, input=0x54be8591 "av") at cmd_anal.c:4038
#3  0x76f30298 in r_cmd_call (cmd=0x54b68820, input=0x54be8590 "aav") at cmd_api.c:210
#4  0x76ef2990 in r_core_cmd_subst_i (core=0x54ac0ec8 <r>, cmd=0x54be8590 "aav", colon=0x0) at cmd.c:1779
#5  0x76ef0890 in r_core_cmd_subst (core=0x54ac0ec8 <r>, cmd=0x54be8590 "aav") at cmd.c:1240
#6  0x76ef4008 in r_core_cmd (core=0x54ac0ec8 <r>, cstr=0x54be3078 "aav", log=0) at cmd.c:2185
#7  0x76ef48c8 in r_core_cmd_str (core=0x54ac0ec8 <r>, cmd=0x54be3078 "aav") at cmd.c:2370
#8  0x76eee4b8 in cmd_interpret (data=0x54ac0ec8 <r>, input=0x54be2f69 "aav") at cmd.c:574
#9  0x76f30298 in r_cmd_call (cmd=0x54b68820, input=0x54be2f68 ".aav") at cmd_api.c:210
#10 0x76ef2990 in r_core_cmd_subst_i (core=0x54ac0ec8 <r>, cmd=0x54be2f68 ".aav", colon=0x0) at cmd.c:1779
#11 0x76ef0890 in r_core_cmd_subst (core=0x54ac0ec8 <r>, cmd=0x54be2f68 ".aav") at cmd.c:1240
#12 0x76ef4008 in r_core_cmd (core=0x54ac0ec8 <r>, cstr=0x76f72bc4 ".aav", log=0) at cmd.c:2185
#13 0x76ef4694 in r_core_cmd0 (user=0x54ac0ec8 <r>, cmd=0x76f72bc4 ".aav") at cmd.c:2320
#14 0x76ec5558 in cmd_anal_all (core=0x54ac0ec8 <r>, input=0x54be2afa "aa") at cmd_anal.c:3814
#15 0x76ec6330 in cmd_anal (data=0x54ac0ec8 <r>, input=0x54be2af9 "aaa") at cmd_anal.c:4038
#16 0x76f30298 in r_cmd_call (cmd=0x54b68820, input=0x54be2af8 "aaaa") at cmd_api.c:210
#17 0x76ef2990 in r_core_cmd_subst_i (core=0x54ac0ec8 <r>, cmd=0x54be2af8 "aaaa", colon=0x0) at cmd.c:1779
#18 0x76ef0890 in r_core_cmd_subst (core=0x54ac0ec8 <r>, cmd=0x54be2af8 "aaaa") at cmd.c:1240
#19 0x76ef4008 in r_core_cmd (core=0x54ac0ec8 <r>, cstr=0x54be3720 "aaaa", log=1) at cmd.c:2185
#20 0x76e98e08 in r_core_prompt_exec (r=0x54ac0ec8 <r>) at core.c:1527
#21 0x54aaf42c in main (argc=3, argv=0x7efff514, envp=0x7efff524) at radare2.c:879

[crowell]

as discussed on tg, the segfault is fixed, the native step is still broken.

[crowell]

and my rpi2 is fucked, i have to reinstall, i'll do this tomorrow night...

[radare]

there's absolutely no problem in receiving SIGILL, i have bought an rpi3, installed raspbian, compiled r2 from git and, after sertting up dbg.swstep the stepping, breakpoints, continue, works as expected. the sigill means that i'm using an illegal instruction as a breakpoint. but this is no issue at all. i'll do some more tests and try to make r2 better on rpi.

[diouziou]

when you say "after setting up dbg.swstep" you mean e dbg.swstep = true, right ?
if so, i still can't make it work :(

• the code stops at the breakpoint as it should (after db addr; dc) (with the SIGILL, that i now understand is used on purpose)
• but it cannot continue when using dc again, indeed i get:

Breakpoint already set at this address.
[+] signal 4 aka SIGILL received 0
[+] signal 4 aka SIGILL received 0

(btw this is on a new install, using noobs)

[radare]

you have to unset the breakpoint to continue, otherwise its stopping in there.

if you want to use breakpoints just to stop at that address use dcu which is much handier

On 19 Apr 2016, at 12:25, diouziou [email protected] wrote:

when you say "after setting up dbg.swstep" you mean e dbg.swstep = true, right ?
if so, i still can't make it work :(

the code stops at the breakpoint as it should (after db addr; dc) (with the SIGILL, that i now understand is used on purpose)
but it cannot continue when using dc again, i get:
Breakooint already set at this address.
[+] signal 4 aka SIGILL received 0
[+] signal 4 aka SIGILL received 0
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #4612 (comment)

[diouziou]

OK, thx
i'm used to being able to use dc (or ds) again, after stopping at a breakpoint, on x86 (or x86_64), which simply works
just for my info, before closing this: what is the reason for the difference in behavior between r2 on x86 (or x86_64) and on arm (if this is generic for arm, otherwise read rpi) ?

[radare]

let’s say this is a bug in dbg.swstep, not related to x86 or arm. because the same issue can be reproduced on x86 when enabling swstep

On 19 Apr 2016, at 13:29, diouziou [email protected] wrote:

OK, thx
i'm used to being able to use dc (or ds) again, after stopping at a breakpoint, on x86, which simply works
just for my info, before closing this: what is the reason for the difference in behavior between r2 on x86 and on arm (if this is generic for arm, otherwise read rpi) ?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #4612 (comment)

[diouziou]

ok, so i let you judge whether or not an issue should be open to suggest taking care of this "bug" and i close this issue.
thx a lot