Binutils is too 'powerfull'

[hellow554]

When I compile a file, using clang (or gcc) for arm

clang++ -target arm-none-eabi a.cpp -c

and then try to open it with emilpro, it will exit with the error

Error: not matching File format is ambiguous

I spent some time to figure out why, and then solution came out of the sudden. Binutils knows way to many file formats and some of them are not very different. Why I try to open a.o with the (for emilpro) compiled binutils, it will spit out

./objdump  -D /home/marcel/a.o
./objdump: /home/marcel/a.o: File format is ambiguous
./objdump: Matching formats: elf32-littlearm elf32-littlearm-symbian elf32-littlearm-vxworks

The sollution is to provide objdump the format with the -b switch, e.g.

./objdump  -D /home/marcel/a.o -b elf32-littlearm

this will work. My proposed solution would be:

console

1. Try to open the file
2. If objdump says it's ambigous, print the matching formats and exit (currently it will still open the gui)
3. Make a command line argument (e.g. -b) where you can specify the format if it's not valid, objdump will print that out( /objdump -D /home/marcel/a.o -b x86 ./objdump: /home/marcel/a.o: Invalid bfd target)

   gui

4. Show the open dialog
5. Add an drop-down box where you can manually specify the target format (and also an auto item, to detect it automaticly!)
6. if it does not match, show an error box (if auto, display all matchinf formats) and let the user try an other target

[SimonKagstrom]

Interesting. I wonder what difference the symbian/vxworks formats really are about - it should still be the same instruction set.

Anyway, I'll have to look a bit more into this. emilpro does not use objdump, but the binutils library directly - so I'll have to check how to specify the format from the API. I wonder if it would be possible to simply specify a "lowest common denominator", .e.g., elf32-littlearm in this case. I've disassembled ARM binaries before with emilpro without issues, so I think this might depend a bit on the toolchain.

And as for the GUI, I've been planning for a long time to replace the GTK gui with a Qt ditto, so I'd be a bit reluctant to add more features to the GTK port. The Qt GUI is "almost there", but not quite yet.

[phros]

I have the same problem with getting the "Error: not matching fileformat..." for every file I wanna open. I tried some self compiled ARM and x86-64 binaries. One of these was the "file-to-source" binary created by the Makefile.

I cloned and build the project today. Any help?

[SimonKagstrom]

Do you have libcapstone-dev installed? With capstone, binutils should not be used for either ARM nor x86-64.

[phros]

Yes, I have libcapstone-dev installed.

[SimonKagstrom]

Are you able to upload the file-to-source binary somewhere so that I can take a look at it?

[phros]

here's a link to the file-to-source binary I tried. Basically the behaviour is similar with every other binary I tried to open.

https://drive.google.com/file/d/0BxRFBmc7gxpgR1AzQXBtbDVOVU0/view

[SimonKagstrom]

Thanks! Although perhaps it's the other way around, i.e., being caused by libcapstone? You can try by editing src/capstone-disassembly.cc and return 0 from CapstoneDisassembmblerProvider::match() and building emilpro.

[phros]

I did the patch in CapstoneDisassembmblerProvider::match() and called "make" again. Nothing changed.

Then I tried to rebuild everything and cloned the project again. Now make fails to build binutil-gdb:

fatal: Reference is no "Tree"-Object: 6711b7f8d5f5fa24d6e44ccbe76fce12bd162a37 CMakeFiles/binutils.dir/build.make:61: recipe for target '.binutils-downloaded' failed

[SimonKagstrom]

Sorry, the binutils build stuff should now be fixed with f29254b213746a840b47e9afabf3a80f3b862e64.

[phros]

Ok, thanks. Compiling works again!

But my problem stays. With the file-to-source binary I don't get any stdout but the emilpro does not show anything. With my other binaries the "file format" error still exists...

[SimonKagstrom]

Good. I tried at another computer again with your file, but unfortunately it opens just fine so something is strange at either your or my setup. What system are you using? I've tested it under both Ubuntu 14.04 and Fedora 22.

[phros]

I am using Ubuntu 14.10 64bit. Also I am writing my own application based on the capstone-lib (https://github.com/aquynh/capstone/tree/next). Maybe with building this and other stuff related to it some dependencies of emilpro are causing problems. I will set up a virtual machine and try it there!

Thanks a lot for our help! Its much appreciated!

[nihilus]

I've the same issue for my BFD-backend to snowman... Did you guys fixed the QT-dialog?

[SimonKagstrom]

The QT gui is usable, but still lacking part of the functionality in the GTK port. It can be built with

mkdir bld
cd bld
cmake ../src/qt/
make

[nihilus]

doesn't build with QT4(?)

[nihilus]

also you should use something like bfd_simple_get_relocated_section_contents in simple.c for doing the relocation of addresses.

[SimonKagstrom]

I started with Qt4, but have since moved to Qt5 - probably it's not compatible with Qt4 anymore.

Thanks for the relocation hint, I'll look into it!

[SimonKagstrom]

8 years later, the reimplemented version has basic support for selecting architecture, so closing this.