[#7313] bfin-gdbproxy crashes when attempting to load an executable on Windows

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#7313] bfin-gdbproxy crashes when attempting to load an executable on Windows

Submitted By: Andrew McLachlan

Open Date

2012-09-06 09:23:59    


High     Assignee:

Andrew McLachlan


N/A     Silicon Revision:


N/A     Fixed In Release:




Host Operating System:


toolchain rev.:

    kernel rev.:


Open     Found In Release:


Is this bug repeatable?:


Summary: bfin-gdbproxy crashes when attempting to load an executable on Windows



1, cd <a working directory>


2, Run bfin-gdbproxy in CMD

    Remote proxy for GDB, v0.7.2


3, Run bfin-elf-gdb in a separate CMD


4, In bfin-elf-gdb -- target remote:2000


5, load fooBar (attached)


6, See crash box (screenshot attached)


This happens using a gnICE jtag or ICE-100B (modified to work with GNU tools).

Connected to ADSP-BF609.




--- Jie Zhang                                                2012-09-06 11:04:04

"File not found." for fooBar and Capture.PNG.


--- Andrew McLachlan                                         2012-09-06 11:11:39


The fooBar binary is just an empty "int main() { return 0; }"


The Capture.PNG was a screenshot showing my version, which is in the

description anyway, and a picture of the oh so helpful crash box.


Let me know if you are able to reproduce the issue using the steps above

and an empty main program built for bf609-any.


--- Jie Zhang                                                2012-09-06 11:14:19

What's the command line you used for building fooBar?


--- Andrew McLachlan                                         2012-09-06 11:22:26


Building file: ../src/fooBar.c

Invoking: Blackfin ELF C Compiler

bfin-elf-gcc -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=bf609-any -MMD -MP

-MF"src/fooBar.d" -MT"src/fooBar.d" -o

"src/fooBar.o" "../src/fooBar.c"


Building target: fooBar

Invoking: Blackfin ELF C Linker

bfin-elf-gcc -mcpu=bf609-any -o "fooBar"  ./src/fooBar.o  

Finished building target: fooBar


--- Jie Zhang                                                2012-09-06 11:38:53

After "target" but before "load", try this:


(gdb) info thread


What do you see?


--- Andrew McLachlan                                         2012-09-06 11:42:12


GNU gdb 6.6

This GDB was configured as "--host=i386-mingw32msvc


(gdb) target remote:2000

Remote debugging using :2000

[New Thread 1]

[New Thread 2]

0xffa0883a in ?? ()

(gdb) info thread

  2 Thread 2 (Core 1 DBGSTAT [0x1000])  0x038c00a3 in ?? ()

* 1 Thread 1 (Core 0 DBGSTAT [0x0018])  0xffa0883a in ?? ()



--- Jie Zhang                                                2012-09-06 13:09:51

This issue should have been fixed in trunk. You are trying to load program into

Core 1, which is locked. The gdbproxy in 2012R1 release has a bug which prevent

it from loading the program. Two workarounds are available:


1. Build the program for Core 0 instead of Core 1 with proper GCC options

"-mmulticore -mcore0". So this bug will not triggered. Actually I

think GCC should generate code for Core 0 by default.


2. You can build gdbproxy from the trunk and replace the executable in 2012R1

installation with the one. With the new gdbproxy, you can load the program into

Core 1 even it's locked, but if you want to execute it, you will need add option

"--unlock-on-connect" to gdbproxy to unlock the Core 1.


--- Andrew McLachlan                                         2012-09-07 04:24:44


Thanks. So there are three items here:


1, I need to check when the gdbproxy bug that prevents the program from


    will make it into the Release.


2, "GCC should generate code for Core 0 by default"

    Chase up to see if we can make it so.


2, The Eclipse plug-in needs to ensure the -mcore option is set when

    creating Projects for Devonshire (and presumably similar for ADSP-BF561).












File Name     File Type     File Size     Posted By

fooBar    application/octet-stream    32992    Andrew McLachlan

fooBar    application/octet-stream    32992    Andrew McLachlan

Capture.PNG    image/png    234920    Andrew McLachlan