[#7313] bfin-gdbproxy crashes when attempting to load an executable on Windows
Submitted By: Andrew McLachlan
Open Date
2012-09-06 09:23:59
Priority:
High Assignee:
Andrew McLachlan
Board:
N/A Silicon Revision:
Resolution:
N/A Fixed In Release:
N/A
Processor:
ALL
Host Operating System:
Windows
toolchain rev.:
kernel rev.:
State:
Open Found In Release:
2012R1
Is this bug repeatable?:
N/A
Summary: bfin-gdbproxy crashes when attempting to load an executable on Windows
Details:
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.
Follow-ups
--- 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; }"
program.
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
E:\EclipseSDK\workspace\fooBar\Debug>bfin-elf-gdb
GNU gdb 6.6
This GDB was configured as "--host=i386-mingw32msvc
--target=bfin-elf".
(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 ?? ()
(gdb)
--- 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
loading
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).
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
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
