edb-debugger

May 19, 2018 6 Replies

Hi!



Since edb is supposed to run on aarch32, I'm trying to compile it on a Pi3b+ running a 32-bit raspian stretch, with the example from here:


This worked fine on x86 and x86_64 debian stretch, but on the Pi this happens:



cmake .. runs without errors, but then make stops at that point: ############################################################ [ 4%] Building CXX object src/CMakeFiles/edb.dir/capstone-edb/Instruction.cpp.o /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp: In


/home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:45:23:


if (operand->type != X86_OP_REG) ^~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp: In


/home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:65:23:


if (operand->type == X86_OP_REG && !is_simd_register(operand)) ^~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:67:23:


if (operand->type == X86_OP_IMM) ^~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp: In


/home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:78:19:


if (op->type == X86_OP_REG && X86_REG_K0 reg && op->reg type == X86_OP_REG) { ^~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp: In


/home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:479:19:


if (op->type == X86_OP_REG && X86_REG_K0 reg && op->reg type != X86_OP_IMM) ^~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp: In


/home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:1100:9:



if(op.access==CS_AC_WRITE && op.type==CS_OP_REG && op.reg==ARM_REG_PC) ^~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:1100:17:



if(op.access==CS_AC_WRITE && op.type==CS_OP_REG && op.reg==ARM_REG_PC) ^~~~~~~~~~~ /home/pi/src/edb-debugger/src/capstone-edb/Instruction.cpp:1100:41:


if(op.access==CS_AC_WRITE && op.type==CS_OP_REG && op.reg==ARM_REG_PC) ^~~~~~~~~ src/CMakeFiles/edb.dir/build.make:214: recipe for target 'src/CMakeFiles/edb.dir/capstone-edb/Instruction.cpp.o' failed make[2]: *** [src/CMakeFiles/edb.dir/capstone-edb/Instruction.cpp.o] Error 1 CMakeFiles/Makefile2:86: recipe for target 'src/CMakeFiles/edb.dir/all' failed make[1]: *** [src/CMakeFiles/edb.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2 ############################################################# Any suggestions?


aen

If the developers think it should compile and run on ARM, then you've found a bug which they'd probably like to know about - they may not have tried to compile it on a Pi 3 yet, so do them a favour by raising a bug.

Martin | martin at Gregorie | gregorie dot org

... or fix it yourself and send them the fix.

Martin | martin at Gregorie | gregorie dot org

This is just a hobby for me, so I wouldn't even know how to "raise a bug", and I don't like it that you always have to register somewhere to do such things.

But thanks, I seem to haven't done anything wrong in my compilation attempt at least.

aen

Go to the project page where you downloaded the edb-debugger source and look for a menu item like 'Bugzilla', 'Bug reporting', or a similar name. Most bug reporting tools are fairly self-explanatory and use a web page that you fill in to report a bug.

Yes, you'll have to register before you can submit a bug report, but whats the problem with that?

The authors spent time and effort writing the code you've downloaded for free, so its reasonable that you help them by reporting bugs or, even better if you have programming skills, fix the bug and submit your patch so the authors can apply it to their master source.

Probably true, as long as you've read the README, but reporting the compilation failure as a bug may get you a known environment-dependent workround. One thing is certain: by NOT reporting it, you've offloaded the reporting duty onto somebody else and probably delayed getting a fix.

Martin | martin at Gregorie | gregorie dot org

On Sat, 19 May 2018 20:02:32 GMT, snipped-for-privacy@spamtrap.com declaimed the following:

Change the compiler options to not warn on enum comparisons?

That would clean up 75% of that dump...

The lack of member errors, OTOH, indicates incompatible header files to me -- you'd have to look at which x86 header file declares a structure with the particular member, and then find the ARM header file that is being included in place of it; then look for the structure to see how it differs.

Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

Didn't find a bugzilla or similar, but in the "Port to ARM" thread in the "Issues" section on the project page I found that the aarch32 support isn't quite finished yet, so it isn't a bug anyway.

I'll just have to wait until it is finished.

aen

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required