Supported Binary Types and Compiler Settings

[deadly-lurker]

I've compiled the repo and am able to successfully run the Busbox sample binary. However none of the elf/bFLT files I compile will run. I've tried the following:

• Compile with bfin-elf-gcc -mcpu=bf518 which gives the error Error mapping file: Cannot allocate memory
• Compile with bfin-elf-gcc -mcpu=bf518 -mfdpic which gives a segfault. Tried this option as I noticed the busybox binary had the fdpic flag set and I wasn't sure if this was necessary for QEMU
• Compile with bfin-uclinux-gcc -mcpu=bf518 gives the error BINFMT_FLAT: reloc outside program 0x400003a (0 - 0x4560/0x3a60)

I've got the 2014 toolchain and have verified that the bFLT file at least does run on real hardware. The program I'm compiling to test is just a simple hello_world, which also compiles fine on native hardware

Could you give some insight or suggestions on where I'm going wrong and what I should be doing to get some code compiled to run on the bfin QEMU port? My end goal is to get bFLT files that have been compiled without any special compiler options running, but even FDPIC ELF binaries would be a step in the right direction

Thanks

[vapier]

these used to work. but tbh, the main test suite just uses bfin-elf-gcc with default settings, so it might have broken a while back and i didn't notice.

i'll look into the FLAT support and expand the testsuite so it doesn't regress again. i know that has broken in the past due to common code changes.

for FDPIC, i would only try bfin-linux-uclibc as that's the only one we ever validated in Linux userland. bfin-elf targets bare-metal.

[deadly-lurker]

Good to know it's not just me, thanks for looking into it. I'd like to start learning more about QEMU but right now I don't even know where I'd start looking to get this fixed.

Also useful to know about FDPIC with uclibc, I do remember reading that bfin-elf targets bare metal now you mention it. Still finding my feet with Blackfin, but difficult to actually find stuff since uClinux, GCC, etc. went end of life and the docs site isn't available any more. Wayback Machine only gets me so far

[vapier]

the initial error you highlighted is indeed due to a bug in common code. i sent a patch upstream for it.
https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg06298.html

it still doesn't work in the end ... i need to debug more. but i'm having some storage issues and won't be able to look more for a while.

[deadly-lurker]

No worries, I have been able to compile with bfin-linux-uclibc and got that working fine. Just curious, what's the GDB support like? Trying to connect with the -g option but GDB just spits out Ignoring packet error, continuing. Turns out I can connect with netcat and when I kill the connection the binary continues running. Thought it might be an issue with my GDB but tried a few variants and got errors with all them. I did notice you repurposed the -s flag and -S isn't supported, but don't think that matters as it seems like QEMU halts until the debugger connects. Wireshark even shows traffic between them, although I need to spend some time learning what that traffic should actually look like to see if there's an issue there

[vapier]

you're trying to use qemu's integrated gdb stub ? i've had a hell of a time making that thing work, and not just Blackfin-specifically. i've reported issues upstream in the past.

I did notice you repurposed the -s flag

did i ? didn't mean to ... i'll add that to the TODO

[deadly-lurker]

Trying is one word for it I guess, although if you're aware of any better alternatives I'd happily switch to something else. Definitely showing my naivety with QEMU

did i ? didn't mean to ... i'll add that to the TODO

Regarding -s, I believe in regular QEMU the -s flag is shorthand for -gdb tcp::1234. And then -S is to halt immediately until GDB connects. But bfin-qemu --help mentions -s is used to set the stack size instead. Which doesn't inherently break anything, since you've got -g is for defining a port, I assume used in place of -gdb. Even though -S isn't supported it does still seem like bfin-qemu halts immediately. So I'm wondering if -g is actually the equivalent of -S -gdb tcp::port which although confusing does the required stuff right up until GDB connects and it all falls over

I'll do some more digging tomorrow to see if I can find out where the gdb stub breaks. There's a fairly specific series of packets being sent in tandem with each error which should give me a decent idea of what exactly is "wrong" with the reply