Compile compat issue of ppc at linux_debug.c, added: reg/linux_ppc.h tested with: configure --disable-debugger at sys/build.sh

[unixfreaxjp]

On cpu:

cpu             : 740/750
temperature     : 62-64 C (uncalibrated)
clock           : 266.000000MHz
revision        : 3.1 (pvr 0008 0301)
bogomips        : 33.20
timebase        : 16601533
platform        : PowerMac
model           : Power Macintosh
machine         : Power Macintosh
motherboard     : AAPL,PowerMac G3 MacRISC
detected as     : 49 (PowerMac G3 (Silk))
pmac-generation : OldWorld
Memory          : 256 MB

Compilation was tested using several methods & permission:

1. sys/user.sh (non root)
2. sys/install.sh (root)
3. cd ~/radare2&&./configure&&make

After several "minor" warnings, the error is getting more serious.. This is where serious errors came up..."e.g. unsupported cpu??"

[...]
p/native/linux/linux_debug.c: In function linux_reg_profile・
p/native/linux/linux_debug.c:28:2: error: #error "Unsupported Linux CPU"
p/native/linux/linux_debug.c: In function linux_handle_signals・
p/native/linux/linux_debug.c:43:2: warning: #warning DO MORE RDEBUGREASON HERE [-Wcpp]
p/native/linux/linux_debug.c: In function print_fpu・
p/native/linux/linux_debug.c:291:2: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c: In function linux_reg_read・
p/native/linux/linux_debug.c:376:3: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c:383:4: error: unknown type name _DEBUG_REG_T・
p/native/linux/linux_debug.c:296:7: warning: variable howfpu・set but not used [-Wunused-but-set-variable]
p/native/linux/linux_debug.c: In function linux_reg_write・
p/native/linux/linux_debug.c:425:43: error: struct user・has no member named 穹_debugreg・
p/native/linux/linux_debug.c:431:17: error: _DEBUG_REG_T・undeclared (first use in this function)
p/native/linux/linux_debug.c:431:17: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c:444:48: error: egs・undeclared (first use in this function)
CC asm_malbolge.c
p/native/linux/linux_debug.c: At top level:
p/native/linux/linux_debug.c:203:13: warning: print_fpu・defined but not used [-Wunused-function]
CC asm_mcs96.c
p/native/linux/linux_debug.c: In function Linux_reg_profile・
p/native/linux/linux_debug.c:30:1: warning: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [p/native/linux/linux_debug.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC asm_mips_cs.c
CC asm_mips_gnu.c
CC mips-dis.c
make[3]: *** [foo] Error 2
make[2]: *** [debug] Error 2
make[2]: *** Waiting for unfinished jobs....
CC mips16-opc.c
CC mips-opc.c
CC mipsasm.c
[...]

And this is the "kills" for the compilation session..

CC elf32-xtensa.c
CC asm_z80.c
CC asm_z80_cr.c
CC asm.c
CC code.c
asm.c: In function xxx_asm_new・
asm.c:131:14: warning: unused variable static_plugin・[-Wunused-variable]
LD libr_asm.so
CC asm_propeller.c
CC propeller_disas.c
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
make[1]: *** [all] Error 2
make: *** [all] Error 2
Oops

Suggested problem:

Compatibility problem? Unsupported cpu? Overlapping in linking before "make" process itself?
(please enlight us)

More longer compilation log is in here: https://github.com/unixfreaxjp/dev/blob/master/r2ppc.md

[crowell]

the unsupported CPU message comes from here:

const char *linux_reg_profile (RDebug *dbg) {
#if __arm__
#include "reg/linux-arm.h"
#elif __arm64__ || __aarch64__
#include "reg/linux-arm64.h"
#elif __MIPS__ || __mips__
#include "reg/linux-mips.h"
#elif (__i386__ || __x86_64__)
  if (dbg->bits & R_SYS_BITS_32) {
#if __x86_64__
#include "reg/linux-x64-32.h"
#else
#include "reg/linux-x86.h"
#endif
  } else {
#include "reg/linux-x64.h"
  }
#else
#error "Unsupported Linux CPU"
#endif
}

can you try this patch? https://gist.github.com/ae283ea135d5be56388042f49d24418c

[crowell]

(sparc should also fail because it doesn't have a reg profile in the debug plugin.)

[unixfreaxjp]

The idea is if Mac OSX works, why not for PowerMac since it shares similar architecture for ppc routers . I choose 3G since it is generic enough and has some emulation built.

the unsupported CPU message comes from here:

I must work, at least the static functions. The below msg doesn't support debug on ppc (mind the garbled JP mode characters):

p/debug_native.c:1320:2: warning: #warning Unsupported architecture [-Wcpp]
p/native/linux/linux_debug.c: In function ▒linux_reg_profile▒:
p/native/linux/linux_debug.c:28:2: error: #error "Unsupported Linux CPU"
p/native/linux/linux_debug.c: In function ▒linux_handle_signals▒:
p/native/linux/linux_debug.c:43:2: warning: #warning DO MORE RDEBUGREASON HERE [-Wcpp]
p/native/linux/linux_debug.c: In function ▒print_fpu▒:
p/native/linux/linux_debug.c:291:2: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c: In function ▒linux_reg_read▒:
p/native/linux/linux_debug.c:376:3: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c:383:4: error: unknown type name ▒R_DEBUG_REG_T▒
p/native/linux/linux_debug.c:296:7: warning: variable ▒showfpu▒ set but not used [-Wunused-but-set-variable]
p/native/linux/linux_debug.c: In function ▒linux_reg_write▒:
p/native/linux/linux_debug.c:425:43: error: ▒struct user▒ has no member named ▒u_debugreg▒
p/native/linux/linux_debug.c:431:17: error: ▒R_DEBUG_REG_T▒ undeclared (first use in this function)
p/native/linux/linux_debug.c:431:17: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c: At top level:
p/native/linux/linux_debug.c:203:13: warning: ▒print_fpu▒ defined but not used [-Wunused-function]
p/native/linux/linux_debug.c: In function ▒linux_reg_profile▒:
p/native/linux/linux_debug.c:30:1: warning: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [p/native/linux/linux_debug.o] Error 1
make[4]: *** Waiting for unfinished jobs....

can you try this patch? https://gist.github.com/ae283ea135d5be56388042f49d24418c

okay, tried this patch, it failed. < EDITED↓ EDIT: Re-evaluated, patch wrongly applied, is re-applying the patch, test is OPEN for this patch now.

Other step is testing the below advise:

Frankly, I have no confident in configuration option. So I took some tests [https://github.com/unixfreaxjp/dev/blob/master/r2ppc-2.md] Ending up by patching these code in sys/build.sh for triggering the "fixed" option --disable-debugger:

Hang on gents, the cpu is slow. On it. On going report is updated in URL above..

[unixfreaxjp]

The option --disable-debugger configured well:

Final report:
 - PREFIX = /test/bin/prefix/radare2/
 - HAVE_LIB_GMP = 0
 - HAVE_OPENSSL = 0
 - USE_CAPSTONE = 0
 - HAVE_FORK = 1
 - VERSION = 0.10.3-git
 - USE_LIB_ZIP = 0
 - USE_LIB_MAGIC = 0
 - DEBUGGER = 0 <=========================== Yes!
 - CC = gcc
 - USERCC = gcc
 - USEROSTYPE = gnulinux
 - LIL_ENDIAN = 0
 - LIBVERSION = 0.10.3-git
Generating r_version.h file [...]

Build environment is correct too:

BUILD SUMARY
============
COMPILER gcc
CC gcc
HOST_CC gcc
HOST_OS linux
BUILD_OS linux
============

But it can not built, somehow during the compilation process _it still linked to native Linux compiler _even the debugger is disabled. Below is the collected warning snipped until it stop the build due to error.

                  [...]
calc.c: In function 'r_hash_calculate':
calc.c:39:8: warning: unused variable 'pres' [-Wunused-variable]
                  [...]
CC cr16_disas.c
/test/radare2/libr/..//libr/bin/p/bin_elf.c:581:15: warning: 'patch_relocs' defined but not used [-Wunused-function]
CC dex.c
                  [...]
CC utils.c
CC hashtable.c
CC hashvector.c
CC pe64.c
CC bin_pebble.c
CC bin_psxexe.c
/test/radare2/libr/..//libr/anal/p/../..//asm/arch/tms320/c55x_plus/hashvector.c:97:25: warning: 'ins_hash' defined but not used [-Wunused-variable]
CC anal_v810.c
                  [...]
CC demangler.c
CC microsoft_demangle.c
/test/radare2/libr/..//libr/anal/p/../../asm/arch/z80_cr/z80_tab.h:936:19: warning: 'z80_op' defined but not used [-Wunused-variable]
CC objc.c
                  [...]
CC anal_ex.c
CC switch.c
anal.c: In function 'r_anal_set_reg_profile':
anal.c:205:7: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
CC state.c
                  [...]
CC mmemory.c
CC parse_ppc_pseudo.c
CC parse_x86_pseudo.c
LD libr_parse.so
CC parse_z80_pseudo.c
gcc: warning: /test/radare2/libr/../shlr/zip/librz.a: linker input file unused because linking not done
DIR asm
DIR debug
CC asm_6502.c
CC asm_8051.c

        [...] // here comes the debugger... why it is compiled even it was configured as disabled?
CC debug_bf.c
CC asm_cris_gnu.c
CC cris-dis.c
CC debug_bochs.c
CC debug_esil.c
CC cris-opc.c
CC asm_csr.c
CC asm_dalvik.c
CC asm_dcpu16.c
CC debug_gdb.c
CC asm_ebc.c
CC debug_native.c
CC debug_qnx.c
CC asm_gb.c
CC asm_h8300.c
CC asm_hppa_gnu.c
CC debug_rap.c
CC hppa-dis.c
CC debug_wind.c
CC asm_i4004.c
CC linux_debug.c
CC asm_i8080.c
CC asm_java.c
CC asm_lanai_gnu.c
CC lanai-dis.c
CC lanai-opc.c
CC asm_lh5801.c
CC asm_lm32.c
p/native/linux/linux_debug.c: In function 'linux_reg_profile':
p/native/linux/linux_debug.c:28:2: error: #error "Unsupported Linux CPU"
p/native/linux/linux_debug.c: In function 'linux_handle_signals':
p/native/linux/linux_debug.c:43:2: warning: #warning DO MORE RDEBUGREASON HERE [-Wcpp]
p/native/linux/linux_debug.c: In function 'print_fpu':
p/native/linux/linux_debug.c:291:2: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:376:3: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c:383:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c:296:7: warning: variable 'showfpu' set but not used [-Wunused-but-set-variable]
p/native/linux/linux_debug.c: In function 'linux_reg_write':CC asm_m68k.c

p/native/linux/linux_debug.c:425:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:431:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)
p/native/linux/linux_debug.c:431:17: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c: At top level:
p/native/linux/linux_debug.c:203:13: warning: 'print_fpu' defined but not used [-Wunused-function]
p/native/linux/linux_debug.c: In function 'linux_reg_profile':
p/native/linux/linux_debug.c:30:1: warning: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [p/native/linux/linux_debug.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC m68k_disasm.c
CC asm_m68k_cs.c
CC asm_malbolge.c
make[3]: *** [foo] Error 2
make[2]: *** [debug] Error 2
make[2]: *** Waiting for unfinished jobs....
CC asm_mcs96.c
CC asm_mips_cs.c
CC asm_mips_gnu.c
CC mips-dis.c
CC mips16-opc.c
CC mips-opc.c
CC mipsasm.c
                  [...]
CC asm_z80_cr.c
CC asm.c
CC code.c
LD libr_asm.so
CC asm_propeller.c
CC propeller_disas.c
gcc: warning: /home/mung/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
gcc: warning: /home/mung/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
make[1]: *** [all] Error 2
make: *** [all] Error 2
Oops

Result so far:

1. EDIT: Re-test this patch (OPEN) ae283ea135d5be56388042f49d24418c
2. ./configure --disable-debugger (Done w/o patched above, failed. Re-trying w/above patch..OPEN)

let's see the code slowly now.. really want to know why it still called native linux debugger..

[unixfreaxjp]

Stupid I am, this is INDEED the main problem.

Re-checking the overall process, found that patch ae283ea135d5be56388042f49d24418c wasn't applied correctly.. Now correctly re-applying Jeffrey Crowell crowell@bu.edu patch to:

• libr/debug/p/native/linux/linux_debug.c

[...]
#elif __ppc__
#include "reg/linux-ppc.h"
[...]

and added ppc register list as header (for comparison xref: http://lxr.free-electrons.com/source/arch/powerpc/include/asm/reg.h) file to:

• libr/debug/p/native/linux/reg/linux-ppc.h

return strdup (
"=PC    srr0\n"
"=SP    srr1\n"
"=SR    srr1\n" // status register ??
"=A0    r0\n"
"=A1    r1\n"
"=A2    r2\n"
"=A3    r3\n"
#if 0
"=A4    r4\n"
"=A5    r5\n"
"=A6    r6\n"
"=A7    r7\n"
#endif
"gpr    srr0    .32 0   0\n"
"gpr    srr1    .32 4   0\n"
"gpr    r0  .32 8   0\n"
"gpr    r1  .32 12  0\n"
"gpr    r2  .32 16  0\n"
"gpr    r3  .32 20  0\n"
"gpr    r4  .32 24  0\n"
"gpr    r5  .32 28  0\n"
"gpr    r6  .32 32  0\n"
"gpr    r7  .32 36  0\n"
"gpr    r8  .32 40  0\n"
"gpr    r9  .32 44  0\n"
"gpr    r10 .32 48  0\n"
"gpr    r11 .32 52  0\n"
"gpr    r12 .32 56  0\n"
"gpr    r13 .32 60  0\n"
"gpr    r14 .32 64  0\n"
"gpr    r15 .32 68  0\n"
"gpr    r16 .32 72  0\n"
"gpr    r17 .32 76  0\n"
"gpr    r18 .32 80  0\n"
"gpr    r19 .32 84  0\n"
"gpr    r20 .32 88  0\n"
"gpr    r21 .32 92  0\n"
"gpr    r22 .32 96  0\n"

"gpr    r23 .32 100 0\n"
"gpr    r24 .32 104 0\n"
"gpr    r25 .32 108 0\n"
"gpr    r26 .32 112 0\n"
"gpr    r27 .32 116 0\n"
"gpr    r28 .32 120 0\n"
"gpr    r29 .32 124 0\n"
"gpr    r30 .32 128 0\n"
"gpr    r31 .32 132 0\n"
"gpr    cr  .32 136 0\n"
"gpr    xer .32 140 0\n"
"gpr    lr  .32 144 0\n"
"gpr    ctr .32 148 0\n"
"gpr    mq  .32 152 0\n"
"gpr    vrsave  .32 156 0\n"
);

test continues... test progress report is here: https://github.com/unixfreaxjp/dev/blob/master/r2ppc-2.md Additional: linux-ppc.h is good.

[unixfreaxjp]

test failed, condition: above patch was applied + --disable-debugger.

[...]

CC linux_debug.c
p/native/linux/linux_debug.c: In function 'linux_reg_profile':
p/native/linux/linux_debug.c:30:2: error: #error "Unsupported Linux CPU"
p/native/linux/linux_debug.c: In function 'linux_handle_signals':
p/native/linux/linux_debug.c:45:2: warning: #warning DO MORE RDEBUGREASON HERE [-Wcpp]
p/native/linux/linux_debug.c: In function 'print_fpu':
p/native/linux/linux_debug.c:293:2: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:378:3: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c:385:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c:298:7: warning: variable 'showfpu' set but not used [-Wunused-but-set-variable]
p/native/linux/linux_debug.c: In function 'linux_reg_write':
p/native/linux/linux_debug.c:427:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:433:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)
p/native/linux/linux_debug.c:433:17: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c: At top level:
p/native/linux/linux_debug.c:205:13: warning: 'print_fpu' defined but not used [-Wunused-function]
p/native/linux/linux_debug.c: In function 'linux_reg_profile':
p/native/linux/linux_debug.c:32:1: warning: control reaches end of non-void function [-Wreturn-type]
make[4]: *** [p/native/linux/linux_debug.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [foo] Error 2
make[2]: *** [debug] Error 2
make[2]: *** Waiting for unfinished jobs....
LD libr_asm.so
CC asm_propeller.c
CC propeller_disas.c
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
make[1]: *** [all] Error 2
make: *** [all] Error 2
Oops
~/radare2$

longer test log: https://github.com/unixfreaxjp/dev/blob/master/r2ppc-2.md

Suggestion:

• Result looks fishy.. patch code seem doesn't applied well, too (CHECKING..)

  asm p/native/linux/linux_debug.c: In function 'linux_reg_profile': p/native/linux/linux_debug.c:30:2: error: #error "Unsupported Linux CPU" p/native/linux/linux_debug.c: In function 'linux_handle_signals':

• The p/native/linux/linux_debug.c needs more adjustment (more than the patch) for powerpc (ppc) CPU, either to be added in linux_ppc.h or in linux_debug.c
• Recoding related file(s)
• Still wonder why it is still calling linux_debug.c even --disable-debugger flag is on. We might should see the sys/build.sh for adjustment in building process.
• For me (test) next step is manually executing building process by make & gcc, but I think it will bumped to the same lines

[unixfreaxjp]

shall this be considered as unsupported platform and close the issue? @radare @crowell or to try a bit further? Meanwhile I am still trying..

[unixfreaxjp]

EDIT: As per suggested #if 0 the block codes for these errors:

[1] In function 'linux_reg_profile':
p/native/linux/linux_debug.c:30:2: error: #error "Unsupported Linux CPU"

[2] In function 'linux_reg_read':
p/native/linux/linux_debug.c:385:4: error: unknown type name 'R_DEBUG_REG_T'

[3] In function 'linux_reg_write':
p/native/linux/linux_debug.c:427:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:433:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)

modifying additional test patch for p/native/linux/linux_debug.c:

/* for test purpose @unixfreaxjp */
--- linux_debug.c.TEST  2016-04-28 11:06:32.000000000 +0000
+++ linux_debug.c.ORIG  2016-04-28 03:15:12.004081151 +0000
@@ -27,8 +27,6 @@
 #include "reg/linux-x64.h"
        }
 #else
-
-#if 0
 #error "Unsupported Linux CPU"
 #endif
 }
@@ -380,16 +378,13 @@
        #warning not implemented for this platform
 #endif
                break;
-
-#if 0 commented for ppc */
-       case R_REG_TYPE_SEG:
-       case R_REG_TYPE_FLG:
-       case R_REG_TYPE_GPR:
-               {
+       case R_REG_TYPE_SEG:
+       case R_REG_TYPE_FLG:
+       case R_REG_TYPE_GPR:
+               {
                        R_DEBUG_REG_T regs;
-                       memset (&regs, 0, sizeof (regs));
-                       memset (buf, 0, size);
-
+                       memset (&regs, 0, sizeof (regs));
+                       memset (buf, 0, size);
 #if __arm64__ || __aarch64__
                        {
                        struct iovec io = {
@@ -429,16 +424,13 @@
                long *val = (long*)buf;
                for (i = 0; i < 8; i++) { // DR0-DR7
                        if (i == 4 || i == 5) continue;
-
-#if 0                  if (ptrace (PTRACE_POKEUSER, dbg->pid, r_offsetof (
+                       if (ptrace (PTRACE_POKEUSER, dbg->pid, r_offsetof (
                                        struct user, u_debugreg[i]), val[i])) {
                                eprintf ("ptrace error for dr %d\n", i);
                                perror ("ptrace");
                        }
                }
-
-       return sizeof(R_DEBUG_REG_T);
-
+               return sizeof(R_DEBUG_REG_T);
 #else
                return false;
 #endif

[radare]

i think ppc is wrong. at least on OSX is POWERPC i dont have a native linux on powerpc to test that thing but i pushed some blind commits in master. can you please retry building?

i think --disable-debugger is not properly working now. because all the native debugging capabilities should be avoided if that flag is passed to configure instead of failing here.

[unixfreaxjp]

i think ppc is wrong. at least on OSX is POWERPC

Okay, It is well explained the POWERPC flag then:

$ cat ./libr/debug/p/native/linux/linux_debug.c | egrep '_ppc_|_POWERPC_'
#elif __ppc__   <--- out test patch
#elif __POWERPC__
#elif __POWERPC__

Where/how can I confirm the exact correct flag in this distro? Most of ppc are on ppc by some spotted reference, will powerpc (likely) will do?

i dont have a native linux on powerpc to test that thing but i pushed some blind commits in master. can you please retry building?

Retrying, I am doing the test then, pulling all codes beforehand, with thank you.

[...]
WARNING: Updating from remote repository
remote: Counting objects: 54, done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 54 (delta 19), reused 4 (delta 4), pack-reused 0
Unpacking objects: 100% (54/54), done.
From https://github.com/radare/radare2
   60de2dc..98bcf2c  master     -> origin/master
Updating 60de2dc..98bcf2c
error: Your local changes to the following files would be overwritten by merge:
     libr/debug/p/native/linux/linux_debug.c
Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
     libr/debug/p/native/linux/reg/linux-ppc.h
[...]
Final report:
 - PREFIX = /test/bin/prefix/radare2/
 - HAVE_LIB_GMP = 0
 - HAVE_OPENSSL = 0
 - USE_CAPSTONE = 0
 - HAVE_FORK = 1
 - VERSION = 0.10.3-git
 - USE_LIB_ZIP = 0
 - USE_LIB_MAGIC = 0
 - DEBUGGER = 0
 - CC = gcc
 - USERCC = gcc
 - USEROSTYPE = gnulinux
 - LIL_ENDIAN = 0
 - LIBVERSION = 0.10.3-git
Generating r_version.h file
(con'd)

think --disable-debugger is not properly working now. because all the native debugging capabilities should be avoided if that flag is passed to configure instead of failing here.

Noted, thanks very much for the important statement for the future reference in similar cases avoiding debugging function build.

(additional, if necessary) latest linux_debug.c #if 0 (not confident) tested: https://github.com/unixfreaxjp/dev/blob/master/linux_debug.c

[Latest Update] The new fresh pull test was done with fail in building, the full compile log is here: https://github.com/unixfreaxjp/dev/blob/master/r2ppc-3.md The grep of the "error" part in log is below:

p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:385:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c: In function 'linux_reg_write':
p/native/linux/linux_debug.c:427:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:433:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)

[unixfreaxjp]

Suggestion:

• ibr/.../p/native/linux/linux_debug.c need to be recoded to have skeleton that can support wider possible IoT (1) architecture and (2) cpu
• to consider fixing flag ./configure --disable-debugger for static function build only that can support the build in minimum IoT environment, by avoiding links to p/debug/native/linux/{`related codes'} during build.
• in linux_debug.c, to define flag powerpc or ppc (for ppc) and POWERPC (for mac OSX) should be cleared.

#elif __ppc__ || __powerpc__ || __POWERPC__ 
#include "reg/linux-ppc.h"

• additionally, maybe we should consider sparc architecture too, two ELF malware we faced are on Linux sparc platform: Linux/PnScan & Linux/Encoder older version, I am preparing the test environment as I'm typing this. My point: It's critical issue that malware coder is already steps ahead than developer of tools to dissect them, why I push this matter.

My point: It's going to be critical issue that malware coder is already steps ahead in providing bad ELF for IoT target than developer of tools to dissect them, why I push this matter, and r2 should be leading other tools to handle these platform.

[radare]

@zamaudio do you have a working qemu-ppc right?

@unixfreaxjp can you try submitting a pullreq?

[zamaudio]

I have one, but r2 doesnt compile there on my vm, a PR that works would be useful.

[unixfreaxjp]

@unixfreaxjp can you try submitting a pullreq?

on it

remote: Counting objects: 962, done.
remote: Compressing objects: 100% (126/126), done.
remote: Total 962 (delta 741), reused 682 (delta 682), pack-reused 154
Receiving objects: 100% (962/962), 555.75 KiB | 713 KiB/s, done.
Resolving deltas: 100% (777/777), completed with 304 local objects.
From https://github.com/radare/radare2
   98bcf2c..c1441e5  master     -> origin/master
 * [new branch]      p8f        -> origin/p8f
Updating 60de2dc..c1441e5

stashed mine, using yours..

remote: Counting objects: 106337, done.
remote: Compressing objects: 100% (126/126), done.
remote: Total 106337 (delta 59), reused 0 (delta 0), pack-reused 106211
Receiving objects: 100% (106337/106337), 56.76 MiB | 1.54 MiB/s, done.
Resolving deltas: 100% (75157/75157), done.
Checking out files: 100% (2528/2528), done.

building now..

Final report:
 - PREFIX = /home/mung/bin/prefix/radare2/
 - HAVE_LIB_GMP = 0
 - HAVE_OPENSSL = 0
 - USE_CAPSTONE = 0
 - HAVE_FORK = 1
 - VERSION = 0.10.3-git
 - USE_LIB_ZIP = 0
 - USE_LIB_MAGIC = 0
 - DEBUGGER = 1  //  <==== noted, will start from this flag now
 - CC = gcc
 - USERCC = gcc
 - USEROSTYPE = gnulinux
 - LIBVERSION = 0.10.3-git

In the same place compilation crashed:

CC xtensa-isa.c
CC xtensa-modules.c
CC elf32-xtensa.c
p/native/linux/linux_debug.c: In function 'linux_handle_signals':
p/native/linux/linux_debug.c:45:2: warning: #warning DO MORE RDEBUGREASON HERE [-Wcpp]
p/native/linux/linux_debug.c: In function 'print_fpu':
p/native/linux/linux_debug.c:293:2: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:378:3: warning: #warning not implemented for this platform [-Wcpp]
p/native/linux/linux_debug.c:385:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c:298:7: warning: variable 'showfpu' set but not used [-Wunused-but-set-variable]CC asm_z80.c

p/native/linux/linux_debug.c: In function 'linux_reg_write':
p/native/linux/linux_debug.c:427:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:433:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)
p/native/linux/linux_debug.c:433:17: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c: At top level:
p/native/linux/linux_debug.c:205:13: warning: 'print_fpu' defined but not used [-Wunused-function]
CC asm_z80_cr.c
make[4]: *** [p/native/linux/linux_debug.o] Error 1
make[3]: *** [foo] Error 2
make[2]: *** [debug] Error 2
make[2]: *** Waiting for unfinished jobs....
CC asm.c
CC code.c
LD libr_asm.so
CC asm_propeller.c
CC propeller_disas.c
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
gcc: warning: /test/radare2/libr/../shlr/capstone/libcapstone.a: linker input file unused because linking not done
make[1]: *** [all] Error 2
make: *** [all] Error 2
Oops

Same error in the building p/native/linux/linux_debug.o

p/native/linux/linux_debug.c:385:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c:427:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:433:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)

[unixfreaxjp]

refer to https://github.com/radare/radare2/blob/master/libr/debug/p/native/linux/linux_debug.c compiler seems went straight to line 377......

#else
    #warning not implemented for this platform
#endif

.....and it was ignoring what is expected to be ppc's linux struct fpregs trap in (line: 350-373) by !ANDROID, no? (see below as xref)

#if !__ANDROID__
            struct user_fpxregs_struct fpxregs;
            ret1 = ptrace (PTRACE_GETFPXREGS, pid, NULL, &fpxregs);
            if (ret1 == 0) {
                if (showfpu) print_fpu ((void *)&fpxregs, ret1);
                if (sizeof(fpxregs) < size) size = sizeof(fpxregs);
                memcpy (buf, &fpxregs, size);
                return sizeof(fpxregs);
            } else {
                ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
                if (showfpu) print_fpu ((void *)&fpregs, ret1);
                if (ret1 != 0) return false;
                if (sizeof(fpregs) < size) size = sizeof(fpregs);
                memcpy (buf, &fpregs, size);
                return sizeof(fpregs);
            }
#else
            ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
            if (showfpu) print_fpu ((void *)&fpregs, 1);
            if (ret1 != 0) return false;
            if (sizeof(fpregs) < size) size = sizeof(fpregs);
            memcpy (buf, &fpregs, size);
            return sizeof(fpregs);
#endif // !__ANDROID__

An idea that may help to fix these..

I think by adding ppc's specific condition like mentioned area will fix the flow, since the user struct fpregs for ppc seems to be unrecognized, judging by the error messages (confident: medium), this is what seems to be a problem in ppc compilation.

To be added (example) after line 349 (didn't check down to references yet)

#elif __ppc__ || __powerpc__ || __POWERPC__
            ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
            if (showfpu) print_fpu ((void *)&fpregs, 1);
            if (ret1 != 0) return false;
            if (sizeof(fpregs) < size) size = sizeof(fpregs);
            memcpy (buf, &fpregs, size);
            return sizeof(fpregs);

if so, we will need to change line 445 to out ptrace with , like: (confident: low)

#elif __ppc__ || __powerpc__ || __POWERPC__
        int ret = ptrace (PTRACE_SETREGS, dbg->pid, &regs, NULL);

Why I think this will work, because please see line: 27-28. The grep for ppc flag architecture used is working in there: (confident: high)

 #elif __ppc__ || __powerpc__ || __POWERPC__
#include "reg/linux-ppc.h"

So it is up to you to decide, first, please judge whether r2 will support this cpu, so we can hack malware & bad firmware in some routers with same arch like this. If this put too much work and need to focus to other development, cracking for this cpu's bad stuff will have to be done in r2 static mode, and that doesn't have to be done in this cpu, or do the ancient methods. I'll go either ways anyway.

[radare]

Make a pull request please

On 12 May 2016, at 00:27, unixfreaxjp notifications@github.com wrote:

refer to https://github.com/radare/radare2/blob/master/libr/debug/p/native/linux/linux_debug.c compiler seems went straight to line 377 -

else

#warning not implemented for this platform

endif

and it was ignoring what is expected to be ppc's linux struct fpregs trap in (line: 350-373) by !ANDROID, no?

if !ANDROID

        struct user_fpxregs_struct fpxregs;
        ret1 = ptrace (PTRACE_GETFPXREGS, pid, NULL, &fpxregs);
        if (ret1 == 0) {
            if (showfpu) print_fpu ((void *)&fpxregs, ret1);
            if (sizeof(fpxregs) < size) size = sizeof(fpxregs);
            memcpy (buf, &fpxregs, size);
            return sizeof(fpxregs);
        } else {
            ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
            if (showfpu) print_fpu ((void *)&fpregs, ret1);
            if (ret1 != 0) return false;
            if (sizeof(fpregs) < size) size = sizeof(fpregs);
            memcpy (buf, &fpregs, size);
            return sizeof(fpregs);
        }

else

        ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
        if (showfpu) print_fpu ((void *)&fpregs, 1);
        if (ret1 != 0) return false;
        if (sizeof(fpregs) < size) size = sizeof(fpregs);
        memcpy (buf, &fpregs, size);
        return sizeof(fpregs);

endif // !ANDROID

Below idea may help to fix these..

I think by adding ppc's specific condition like mentioned area will fix the flow, since the user struct fpregs for ppc seems to be unrecognized, judging by the error messages (confident: medium), this is what seems to be a problem in ppc compilation.

To be added (example) after line 349

elif ppc || powerpc || POWERPC

        ret1 = ptrace (PTRACE_GETFPREGS, pid, NULL, &fpregs);
        if (showfpu) print_fpu ((void *)&fpregs, 1);
        if (ret1 != 0) return false;
        if (sizeof(fpregs) < size) size = sizeof(fpregs);
        memcpy (buf, &fpregs, size);
        return sizeof(fpregs);

if so, we will need to change line 445 to out ptrace with , like: (confident: low)

elif ppc || powerpc || POWERPC

    int ret = ptrace (PTRACE_SETREGS, dbg->pid, &regs, NULL);

Why I think this will work, because please see line: 27-28. The grep for ppc flag architecture used is working in there: (confident: high)

elif ppc || powerpc || POWERPC

include "reg/linux-ppc.h"

So it is up to you to decide, first, please judge whether r2 will support this cpu, so we can hack malware & bad firmware in some routers with same arch like this. If this put too much work and need to focus to other development, cracking for this cpu's bad stuff will have to be done in r2 static mode, and that doesn't have to be done in this cpu, or do the ancient methods. I'll go either ways anyway.

Standing by :)

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

[unixfreaxjp]

Make a pull request please

Hello. You mean me coding " powerpc " compatibility in p/native/linux/linux_debug.c? If so I'll stick to 32bit only (not adding any " powerpc64 " stream since can't test that). It isn't easy, on it. Now I'm forking all, designing/testing/coding after day work. Will pull request after my code tested. Cheers.

[EDIT]

If so I'll stick to 32bit only

Note: No, during this coding session, a lot of previous code that I didn't understand why, so I refer to them, all of the pattern is havng both 32 & 64bit handling, so I use flag powerpc (ppc32 and ppc64) instead of ! powerpc64 (ppc32).

[radare]

You can do a pullreq via web just clicking in the pencil button, everything will be tested automatically

On 12 May 2016, at 09:19, unixfreaxjp notifications@github.com wrote:

Make a pull request please

Hello. You mean me coding " powerpc " compatibility in p/native/linux/linux_debug.c? If so I'll stick to 32bit only (not adding any " powerpc64 " stream since can't test that). It isn't easy, on it. Now I'm forking all, designing/testing/coding after day work. Will pull request after my code tested. Cheers.

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

[unixfreaxjp]

[EDIT] forked+recoded PoC: linux_debug.c|blame and linux_debug.c|hist Status: 1st & 2nd build still failed even some adjustments made. Current saved code is the most stable I can get after these hours. Tested in other platforms (macosx x86-64, linux x64/32 and bsd x32/x64) too to check bad effect, but looks okay, error occured in powepc only. This is not good. With this result I can not pullreq yet (meaningless). The concept is correct: we just need handling for powerpc that's it; I lack of knowledge on previous part of codes in print_fpu(), linux_reg_read() and linux_reg_write() & need much reference on powerpc32 used register itself (i.e. I don't think it supports DRX and/or R_REG_TYPE_GPR).
Below is last stage error:

p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:404:4: error: unknown type name 'R_DEBUG_REG_T'
p/native/linux/linux_debug.c: In function 'linux_reg_write':
p/native/linux/linux_debug.c:446:43: error: 'struct user' has no member named 'u_debugreg'
p/native/linux/linux_debug.c:452:17: error: 'R_DEBUG_REG_T' undeclared (first use in this function)

Sorry, wish to help more. Be right back after recharged. As per discussed in #radare, sent pullreq anyway.

[radare]

r2 builds fine in powerpc now, but it fails to run because of endian problems. moving for 0.10.4

[radare]

please confirm that is fixed

[unixfreaxjp]

on testing mode.. but during check last code heads/master-0-g2f5ead1 before start tests this error came up, it seems like the latest modification is killing freebsd, and mostly all bsd will be affected in that same broken links https://github.com/radare/radare2/issues/5279 Please help to check and kindly let me know if you want to keep on testing arm/mips/ppc anyway

EDIT: On testing Linux/PPC build now, will paste the result in next post.

[unixfreaxjp]

@radare @XVilka @Maijin

I test built the committed code as per following detail:

[0x10001c0c]> !r2 -v
radare2 0.10.4-git 11827 @ linux-ppc-32 git.0.10.3-403-g2f5ead1
commit: 2f5ead1efd481af5864acad26fc7307d2555e8f3 build: 2016-07-04
[0x10001c0c]>
[0x10001c0c]> q
powerpc:~/radare2$

The Built test was okay, there is no error that can halt the compiling and linking process. However, just like what happened in MIPS build too, the running test failed with the below two symptoms:

1. Not recognizing the test architecture .. it is still fixable by firing e asm.arch=ppc.
2. Invalid data on pdand pxwhich makes me stopping the further check, assuming same endian problem as per MIPS one. The test-pad data is in here: https://github.com/unixfreaxjp/dev/blob/master/r2ppc-6.md

[radare]

can you share that /bin/nc that is wrongly recognized? is this problem happening only on ppc? i guess thats an issue in the elf parser for bigendian. but at least it builds :D

[radare]

good news is that it compiles on both archs… and there are many endian issues in the elf parser, so that was expected. let’s see if i can have some time after release to fix them all.

thanks

On 04 Jul 2016, at 14:01, unixfreaxjp notifications@github.com wrote:

I test built the committed code as per following detail:

[0x10001c0c]> !r2 -v radare2 0.10.4-git 11827 @ linux-ppc-32 git.0.10.3-403-g2f5ead1 commit: 2f5ead1efd481af5864acad26fc7307d2555e8f3 build: 2016-07-04 [0x10001c0c]> The Built test was okay, there is no error that can halt the compiling and linking process. However, just like what happened in MIPS build https://github.com/radare/radare2/issues/4969#issuecomment-230260879too, the running test failed with the below two symptoms:

1. Not recognizing the test architecture .. it is still fixable by firing e asm.arch=ppc.
2. Invalid data on pdand pxwhich makes me stopping the further check, assuming same endian problem as per MIPS one. The data of the test is in here: https://github.com/unixfreaxjp/dev/blob/master/r2ppc-6.md https://github.com/unixfreaxjp/dev/blob/master/r2ppc-6.md — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/4720#issuecomment-230274722, or mute the thread https://github.com/notifications/unsubscribe/AA3-lrnkzVJKLahvR7wlORFV-tjN3U36ks5qSPX9gaJpZM4IQM5t.

[unixfreaxjp]

good news is that it compiles on both archs… and there are many endian issues in the elf parser, so that was expected. let’s see if i can have some time after release to fix them all.

First of all. You did a great work in pinning the compilation process in PPC and MIPS. A tough task, so, congratulations again. :-)

can you share that /bin/nc that is wrongly recognized? is this problem happening only on ppc? i guess thats an issue in the elf parser for bigendian. but at least it builds :D

I think it doesn't matter about the nc binary, the all binaries are read the same. In this below picture I tested with the "ls". And .. yes, it is the parser for big endian part. It's about time.

No, thank you for achieving this far. PS: we have bigger issue for not compiling in freebsd x86 now.

[radare]

those bins load fine on little -endian. so thats a big-endian specific issue

thanks for the bins

On 04 Jul 2016, at 15:10, unixfreaxjp notifications@github.com wrote:

good news is that it compiles on both archs… and there are many endian issues in the elf parser, so that was expected. let’s see if i can have some time after release to fix them all.

First of all. You did a great work in pinning the compilation process in PPC and MIPS. A tough task, so, congratulations again. :-)

can you share that /bin/nc that is wrongly recognized? is this problem happening only on ppc? i guess thats an issue in the elf parser for bigendian. but at least it builds :D

I think it doesn't matter about the nc binary, the all binaries are read the same. In this below picture I tested with the "ls". And .. yes, it is the parser for big endian part. It's about time. https://camo.githubusercontent.com/b3e2432c850b4e4ce057379d204531d46211b8d0/68747470733a2f2f6c68332e676f6f676c6575736572636f6e74656e742e636f6d2f2d31485669794433525732592f5633706579757a487342492f41414141414141415669492f75645a655853754e69714d34766e345a4d495730314f77444c3961305468687141434c63422f733732302f333030312e504e47 No, thank you for achieving this far. PS: we have bigger issue for not compiling in freebsd x86 now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/4720#issuecomment-230287034, or mute the thread https://github.com/notifications/unsubscribe/AA3-lurtDlHHoqPe7c7URtC6jTNTdbdlks5qSQYxgaJpZM4IQM5t.

[unixfreaxjp]

those bins load fine on little -endian. so thats a big-endian specific issue

As per we discussed this before. Sooner or later the parser has to be adjusted to support "BigEndian", yes it is a bit of work, but right now there's non-ARM DVR, Webcam and TV starting to DDoS internet there, people will need r2 to run on them or its dev environment :) God speed.

I'll help in anyway I can without messing the codes this time..lol :)

[radare]

I'm closing this issue as long as compilation is fixed. Big endian issues will be fixed in the next release. still trying to setup a good-performing big-endian machine to work in

[unixfreaxjp]

I'm closing this issue as long as compilation is fixed. Big endian issues will be fixed in the next release.

copy that. new issue will be then?

[radare]

yep, open an issue to address the big-endian issues in the elf parser

On 06 Jul 2016, at 06:34, unixfreaxjp notifications@github.com wrote:

I'm closing this issue as long as compilation is fixed. Big endian issues will be fixed in the next release.

copy that. new issue will be then?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/4720#issuecomment-230669062, or mute the thread https://github.com/notifications/unsubscribe/AA3-lhOk9CjS9CQz-zMPo9FkYQo0ZAmbks5qSzBxgaJpZM4IQM5t.