[#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    

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

Attachments

Outcomes