2010-11-26 16:08:44     Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

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

2010-11-26 16:08:44     Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Connor Griffith (UNITED STATES)

Message: 96244   

 

Is the debug configuration Blackfin Bare Metal Application (ELF) Simulator supposed to work straight out of the box, meaning, let me set break points, view variables, and step through C code by using all the default settings in the debug configuration? If not, what settings do I need to look into that would need to be defined for my specific setup?

 

To test the debug configuration, I wrote a simple single routine program, built it, and tried running it using the default simulator debug configuration. GDB seemed to connect to the simulator properly, but when I either click the resume button or issue the 'run' GDB command via the Eclipse console, the thread runs to completion without stopping on any breakpoints. It doesn't seem to matter if I use the GUI to define the breakpoints or define them manually.

 

The program and debugger will simply terminate when I tell it to run. I'm not sure if its running successfully, just ignoring the breakpoints, or if it's terminating prematurely because of some error. In the Debug view, I see <terminated>GDB Hardware Debugger (11/26/10 2:44 PM) (Exited. Exit code = 0.) and <terminated, exit value: -1>bfin-elf-gdb (11/26/10 2:44 PM).

 

During the test process, GDB generated this output.

 

No symbol "new" in current context.

target sim

Connected to the simulator.

load

Loading section .text, size 0xf5c vma 0xffa00000

Loading section .init, size 0x12 vma 0xffa00f5c

Loading section .fini, size 0xe vma 0xffa00f6e

Loading section .rodata, size 0x8 vma 0xff800000

Loading section .eh_frame, size 0x4 vma 0xff800008

Loading section .ctors, size 0x8 vma 0xff80000c

Loading section .dtors, size 0x8 vma 0xff800014

Loading section .jcr, size 0x4 vma 0xff80001c

Loading section .data, size 0x81c vma 0xff800020

Start address 0xffa00000

Transfer rate: 48576 bits in <1 sec.

break *_start

Breakpoint 3 at 0xffa00000: file /usr/src/packages/BUILD/blackfin-toolchain-09r1.1/../gcc-4.1/libgloss/bfin/basiccrt.S, line 79.

break main.c:5

Breakpoint 4 at 0xffa00254: file ../src/main.c, line 5.

run

run

 

I don't plan on using the simulator long term. I'm just trying to familiarize myself with the Eclipse debug interface while I wait for my gnIce+ hardware to come in. I'm in the US and apparently there aren't any domestic stockpiles of the boards anywhere. I'm getting mine through Newark and they're sourcing it from somewhere in the UK, which is going to take at least another week or so. Anyways, I'm assuming/hoping that the Blackfin Bare Metal Application (ELF) on JTAG configuration will allow me to do the normal debug stuffs once I have the hardware in hand (and solve any of the setup issues that I encounter).

 

 

 

QuoteReplyEditDelete

 

 

2010-11-26 17:39:50     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96247   

 

what toolchain version exactly are you using ?  2009R1.1 and older had a somewhat limited simulator.  so i wouldnt be surprised if this was how it behaved.  nor are there any plans to fix that since it has been rewritten from the ground up for 2010R1.  and your test case works fine for me with newer versions.

 

$ bfin-elf-gdb ./a.out

(gdb) target sim

Connected to the simulator.

(gdb) load

Loading section .init, size 0x12 lma 0x0

Loading section .text, size 0x7868 lma 0x14

Loading section .fini, size 0xe lma 0x787c

Loading section .rodata, size 0x520 lma 0x788c

Loading section .eh_frame, size 0x18c lma 0x7dac

Loading section .ctors, size 0x8 lma 0x8f38

Loading section .dtors, size 0x8 lma 0x8f40

Loading section .jcr, size 0x4 lma 0x8f48

Loading section .data, size 0x828 lma 0x8f4c

Start address 0x14

Transfer rate: 277376 bits in <1 sec.

(gdb) b *_start

Breakpoint 1 at 0x14: file /usr/local/src/blackfin/git/toolchain/gcc-4.3/libgloss/bfin/crt0.S, line 24.

(gdb) r

Starting program: /home/vapier/a.out

 

Breakpoint 1, _start () at /usr/local/src/blackfin/git/toolchain/gcc-4.3/libgloss/bfin/crt0.S:24

24              link 0xc;

Current language:  auto; currently asm

(gdb)

QuoteReplyEditDelete

 

 

2010-11-29 15:21:11     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Connor Griffith (UNITED STATES)

Message: 96292   

 

I was using 2009R1.1, so I updated to 2010R1-RC4 using the precompiled toolchain at http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseBrowse&frs_package_id=74&br_pkgrlssort_by=release_name&br_pkgrlssort_order=desc.

 

I took a screenshot of the new results. Things still don't seem to work. I get the messages "cannot acccess memory at address 0xffa00274" and "mi_cmd_var_create: unable to create variable object" in the gdb output.

 

I don't have the libgloss source files installed on my machine like you do. I don't think that's an issue though? It's my understanding that all the required library object code is included within the toolchain releases, and not having the source files simply results in me not being able to step through that code at the source level with the debugger. Also, you'll notice that the Disassembly view doesn't contain any valid instructions, only listing ILLEGAL. Does that imply anything?

 

Again, this is running things straight out of the box. As far as I know, the only thing I've specified for the toolchain and simulator is the particular blackfin chip and silicon revision (bf537-0.3). Everything else should be at default settings.

 

SimulatorDebug.png

QuoteReplyEditDelete

 

 

2010-11-29 15:35:01     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96295   

 

i cant tell you why eclipse is showing that.  it's working fine for me on the command line.  you should forget about eclipse while trying to debug things as it's just a huge layer.

 

$ bfin-elf-gdb ./a.out

(gdb) target sim

Connected to the simulator.

(gdb) load

Loading section .text, size 0x77e4 lma 0xffa00000

Loading section .init, size 0x12 lma 0xffa077e4

Loading section .fini, size 0xe lma 0xffa077f6

Loading section .rodata, size 0x520 lma 0xff800000

Loading section .eh_frame, size 0x18c lma 0xff800520

Loading section .ctors, size 0x8 lma 0xff8006ac

Loading section .dtors, size 0x8 lma 0xff8006b4

Loading section .jcr, size 0x4 lma 0xff8006bc

Loading section .data, size 0x828 lma 0xff8006c0

Start address 0xffa00000

Transfer rate: 276320 bits in <1 sec.

(gdb) dis 0xffa00274

Dump of assembler code from 0xffa00274 to 0xffa002b4:

0xffa00274 <main+4>:    R0.H = 0xff80;          /* (-128)       R0=0x0xff800000(-8388608) */

0xffa00278 <main+8>:    R0.L = 0x0;             /* (  0)        R0=0x0xff800000(-8388608) */

0xffa0027c <main+12>:   R1 = FP;

0xffa0027e <main+14>:   R1 += -0xc;             /* (-12) */

0xffa00280 <main+16>:   CALL 0x0xffa0036c <printf>;

0xffa00284 <main+20>:   UNLINK;

0xffa00288 <main+24>:   RTS;

0xffa0028a:     NOP;

0xffa0028c <atexit+0>:  R1 = R0;

0xffa0028e <atexit+2>:  LINK 0x10;              /* (16) */

0xffa00292 <atexit+6>:  R0 = 0x0 (X);           /*              R0=0x0(  0) */

0xffa00294 <atexit+8>:  [SP + 0xc] = R0;

0xffa00296 <atexit+10>: R2 = 0x0 (X);           /*              R2=0x0(  0) */

0xffa00298 <atexit+12>: CALL 0x0xffa0213c <__register_exitproc>;

0xffa0029c <atexit+16>: UNLINK;

0xffa002a0 <atexit+20>: RTS;

0xffa002a2:     NOP;

0xffa002a4 <exit+0>:    [--SP] = (R7:7);

0xffa002a6 <exit+2>:    LINK 0xc;               /* (12) */

0xffa002aa <exit+6>:    R7 = R0;

0xffa002ac <exit+8>:    R1 = 0x0 (X);           /*              R1=0x0(  0) */

0xffa002ae <exit+10>:   CALL 0x0xffa021bc <__call_exitprocs>;

0xffa002b2 <exit+14>:   P2.H = 0xff80;          /* (-128)       P2=0x0xff800000 */

End of assembler dump.

(gdb)

 

the toolchain does not include source code, so that is not a bug.  if you want source listing of toolchain files, install the toolchain source.

QuoteReplyEditDelete

 

 

2010-11-29 18:09:53     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Connor Griffith (UNITED STATES)

Message: 96296   

 

I tried to replicate your steps, but I'm getting same errors from the command line. I'm totally new at using the command-line interface for gdb, so I apologize if I'm missing something that should be obvious here. I'll be looking more into the manual tomorrow.

 

lu-necal@necal-bf-dev:~/workspace/TestSimulator/Debug$ bfin-elf-gdb ./TestSimulator

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-elf"...

(gdb) target sim

Connected to the simulator.

(gdb) load

Loading section .text, size 0x4fc lma 0xffa00000

Loading section .init, size 0x12 lma 0xffa004fc

Loading section .fini, size 0xe lma 0xffa0050e

Loading section .rodata, size 0x8 lma 0xff800000

Loading section .eh_frame, size 0x4 lma 0xff800008

Loading section .ctors, size 0x8 lma 0xff80000c

Loading section .dtors, size 0x8 lma 0xff800014

Loading section .jcr, size 0x4 lma 0xff80001c

Loading section .data, size 0x408 lma 0xff800020

Start address 0xffa00000

Transfer rate: 18976 bits in <1 sec.

(gdb) dis 0xffa00274

warning: bad breakpoint number at or near '0xffa00274'

(gdb) break main.c:12

Breakpoint 1 at 0xffa00274: file ../src/main.c, line 12.

(gdb) dis 0xffa00274

warning: bad breakpoint number at or near '0xffa00274'

(gdb) run

Starting program: /home/lu-necal/workspace/TestSimulator/Debug/TestSimulator

Cannot access memory at address 0xffa00274

(gdb) run

The program being debugged has been started already.

Start it from the beginning? (y or n) y

 

Starting program: /home/lu-necal/workspace/TestSimulator/Debug/TestSimulator

Cannot access memory at address 0xffa00274

(gdb)

QuoteReplyEditDelete

 

 

2010-11-29 18:26:30     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96297   

 

"dis" is a custom helper function of mine.  it wont work unless you too have this custom thing defined.

 

use the full "disassembly" function and give it a symbol to look at.

QuoteReplyEditDelete

 

 

2010-11-30 15:49:42     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Connor Griffith (UNITED STATES)

Message: 96342   

 

Below is the transcript for my running gdb. It shows me printing disassembly, setting breakpoints, and trying to run the program. In this particular example, I experimented a bit with the different methods to specify locations for the break and diassemble commands, but that's not really important..

 

The main problem seems to be the "cannot access memory at address ____" errors. I don't know what's causing that, and haven't been able to obtain very much information on the causes of that error message.

 

Also, I noticed that while the debugger is running, the disassemble command will not function. It will simply report back a bunch of 'ILLEGALS'. Just an observation, don't know if it's relevant. The gdb output showing that is in the attached file.

 

At the moment, I'm continuing my reading of the GDB manual, learning the commands and uses and trying to put myself in a better position to troubleshoot/understand this error.

 

lu-necal@necal-bf-dev:~$ bfin-elf-gdb ~/workspace/TestSimulator/Debug/TestSimulator

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-elf"...

(gdb) target sim

Connected to the simulator.

(gdb) load

Loading section .text, size 0x500 lma 0xffa00000

Loading section .init, size 0x12 lma 0xffa00500

Loading section .fini, size 0xe lma 0xffa00512

Loading section .rodata, size 0x8 lma 0xff800000

Loading section .eh_frame, size 0x4 lma 0xff800008

Loading section .ctors, size 0x8 lma 0xff80000c

Loading section .dtors, size 0x8 lma 0xff800014

Loading section .jcr, size 0x4 lma 0xff80001c

Loading section .data, size 0x408 lma 0xff800020

Start address 0xffa00000

Transfer rate: 19008 bits in <1 sec.

(gdb) disassemble _start _start+30

Dump of assembler code from 0xffa00000 to 0xffa0001e:

0xffa00000 <_start+0>:    R1 = 0x30 (X);        /*        R1=0x30( 48) */

0xffa00002 <_start+2>:    SYSCFG = R1;

0xffa00004 <_start+4>:    R1 = 0x400 (X);        /*        R1=0x0x400(1024) */

0xffa00008 <_start+8>:    P0.L = 0x500;        /* (1280)    P0=0x0x500 */

0xffa0000c <_start+12>:    P0.H = 0xffc0;        /* (-64)    P0=0x0xffc00500(-4193024) */

0xffa00010 <_start+16>:    W[P0] = R1.L;

0xffa00012 <_start+18>:    P0.L = 0xd48;        /* (3400)    P0=0x0xffc00d48(-4190904) */

0xffa00016 <_start+22>:    P0.H = 0xffc0;        /* (-64)    P0=0x0xffc00d48(-4190904) */

0xffa0001a <_start+26>:    R1 = 0x0 (X);        /*        R1=0x0(  0) */

0xffa0001c <_start+28>:    W[P0] = R1.L;

End of assembler dump.

(gdb) disassemble *_start *_start+30

Dump of assembler code from 0xffa00000 to 0xffa0001e:

0xffa00000 <_start+0>:    R1 = 0x30 (X);        /*        R1=0x30( 48) */

0xffa00002 <_start+2>:    SYSCFG = R1;

0xffa00004 <_start+4>:    R1 = 0x400 (X);        /*        R1=0x0x400(1024) */

0xffa00008 <_start+8>:    P0.L = 0x500;        /* (1280)    P0=0x0xffc00500(-4193024) */

0xffa0000c <_start+12>:    P0.H = 0xffc0;        /* (-64)    P0=0x0xffc00500(-4193024) */

0xffa00010 <_start+16>:    W[P0] = R1.L;

0xffa00012 <_start+18>:    P0.L = 0xd48;        /* (3400)    P0=0x0xffc00d48(-4190904) */

0xffa00016 <_start+22>:    P0.H = 0xffc0;        /* (-64)    P0=0x0xffc00d48(-4190904) */

0xffa0001a <_start+26>:    R1 = 0x0 (X);        /*        R1=0x0(  0) */

0xffa0001c <_start+28>:    W[P0] = R1.L;

End of assembler dump.

(gdb) break _start

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Breakpoint 1 at 0xffa00002: file /usr/src/packages/BUILD/blackfin-toolchain-2010R1/gcc-4.3/libgloss/bfin/basiccrt.S, line 79.

(gdb) break *_start

Breakpoint 2 at 0xffa00000: file /usr/src/packages/BUILD/blackfin-toolchain-2010R1/gcc-4.3/libgloss/bfin/basiccrt.S, line 79.

(gdb) break _start

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Note: breakpoint 1 also set at pc 0xffa00002.

Breakpoint 3 at 0xffa00002: file /usr/src/packages/BUILD/blackfin-toolchain-2010R1/gcc-4.3/libgloss/bfin/basiccrt.S, line 79.

(gdb) break main

Breakpoint 4 at 0xffa00278: file ../src/main.c, line 12.

(gdb) run

Starting program: /home/lu-necal/workspace/TestSimulator/Debug/TestSimulator

Cannot access memory at address 0xffa00002

(gdb) break _start

Cannot access memory at address 0xffa00000

(gdb) break *_start

Note: breakpoint 2 also set at pc 0xffa00000.

Breakpoint 5 at 0xffa00000: file /usr/src/packages/BUILD/blackfin-toolchain-2010R1/gcc-4.3/libgloss/bfin/basiccrt.S, line 79.

(gdb) run

The program being debugged has been started already.

Start it from the beginning? (y or n) y

 

Starting program: /home/lu-necal/workspace/TestSimulator/Debug/TestSimulator

Cannot access memory at address 0xffa00002

(gdb) kill

Kill the program being debugged? (y or n) y

(gdb) disassemble main

Dump of assembler code for function main:

0xffa00270 <main+0>:    LINK 0xc;        /* (12) */

0xffa00274 <main+4>:    [FP + 0x8] = R0;

0xffa00276 <main+6>:    [FP + 0xc] = R1;

0xffa00278 <main+8>:    R0 = 0x5 (X);        /*        R0=0x5(  5) */

0xffa0027a <main+10>:    [FP -0xc] = R0;

0xffa0027c <main+12>:    R0 = 0x6 (X);        /*        R0=0x6(  6) */

0xffa0027e <main+14>:    [FP -0x8] = R0;

0xffa00280 <main+16>:    R1 = [FP -0xc];

0xffa00282 <main+18>:    R0 = [FP -0x8];

0xffa00284 <main+20>:    R0 = R1 + R0;

0xffa00286 <main+22>:    [FP -0x4] = R0;

0xffa00288 <main+24>:    R0 = [FP -0x4];

0xffa0028a <main+26>:    R1 = 0xa (X);        /*        R1=0xa( 10) */

0xffa0028c <main+28>:    CC = R0 <= R1;

0xffa0028e <main+30>:    IF CC JUMP 0x0xffa0029c <main+44>;

0xffa00290 <main+32>:    R1 = [FP -0xc];

0xffa00292 <main+34>:    R0 = R1 >> 0x1f;

0xffa00296 <main+38>:    R0 = R0 + R1;

0xffa00298 <main+40>:    R0 >>>= 0x1;

0xffa0029a <main+42>:    [FP -0xc] = R0;

0xffa0029c <main+44>:    R0 = 0x0 (X);        /*        R0=0x0(  0) */

0xffa0029e <main+46>:    UNLINK;

0xffa002a2 <main+50>:    RTS;

End of assembler dump.

(gdb)

 

illegal_assembly

QuoteReplyEditDelete

 

 

2010-12-01 09:38:29     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96372   

 

so it seems breakpoints on simulated L1 inst are failing for some reason.  in the meantime, link with -msim rather than -mcpu=bf537 and the linker script will place things into external memory which should work fine.

QuoteReplyEditDelete

 

 

2010-12-01 09:46:22     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96373   

 

actually, looking a bit more, this behavior is currently expected.  the default environment is "virtual" which means you only get external memory.  if you want something more, you need to specify the "operating" environment.

QuoteReplyEditDelete

 

 

2010-12-01 11:20:34     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Connor Griffith (UNITED STATES)

Message: 96374   

 

Linking as usual, when I specify the operating environment to operating I get the error "_cec_raise: double fault at 0xffa000b6 ! :(." Least, that's when I try to specify the operating environment by issuing the command:

 

(gdb) target sim --env operating

 

When I link using the option -msim instead of -mcpu and use the default virtual operating environment in the simulator, I can debug without any problems. However, if I specify environment operating I get "_cec_raise: double fault at 0x0000047c ! :(."

 

At this point, I'm starting to feel as I have the gist of the debugging down with these tools (my main goal for using the simulator). I could continue to work out the issues with the simulator, but I'm not sure how useful that is to my end goals. Hopefully my JTAG debugging goes a bit more smoothly, once my hardware comes in.

 

For reference, is there any more documentation about the simulator other than http://docs.blackfin.uclinux.org/doku.php?id=toolchain:sim?

QuoteReplyEditDelete

 

 

2010-12-01 11:36:31     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Mike Frysinger (UNITED STATES)

Message: 96375   

 

you should also be specifying the Blackfin model you wish to simulate when connecting to the sim target

 

keep in mind that the operating environment is the same as if you had a Blackfin processor.  you start off in EVT0 and are responsible for managing peripherals (like the UART) yourself.  so if you do something that could cause an exception, but you're at EVT0, then you get a double fault -- just like the hardware.

 

i dont know what you're trying to do, but perhaps the -msim / virtual environment is more suitable for what you're trying to do.

 

our wiki page is about the only source of simulator information that i know of.  upstream doesnt really have any info.  i guess there is --help output you could consult.

QuoteReplyEditDelete

 

 

2010-12-16 19:57:08     Re: Blackfin Bare Metal Application (ELF) on Simulator doesn't stop on breakpoints?

Akash Agarwal (UNITED STATES)

Message: 96820   

 

Hi ,

 

Can you try generatiing the binary wih the -mfdpic option. It may work, as the simulator only supports statically linked FDPIC applications, or the statically linked FLAT .gdb file (rather than the raw FLAT file itself).

 

http://docs.blackfin.uclinux.org/doku.php?id=toolchain:sim#tracing

 

Example: bfin-elf-gcc -mfdpic HelloWorld.c -o HelloWorld

 

Thanks

 

Akash

Attachments

    Outcomes