[#6246] Application fails under simulator, first run on GDB. Passes further executions under GDB

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

[#6246] Application fails under simulator, first run on GDB. Passes further executions under GDB

Submitted By: David Gibson

Open Date

2010-09-08 11:09:04     Close Date

2010-09-13 06:40:58

Priority:

Medium     Assignee:

David Gibson

Board:

N/A     Silicon Revision:

Resolution:

Rejected     Fixed In Release:

N/A

Processor:

ALL     

Host Operating System:

toolchain rev.:

    kernel rev.:

State:

Closed     Found In Release:

N/A

Is this bug repeatable?:

yes     

Summary: Application fails under simulator, first run on GDB. Passes further executions under GDB

Details:

 

The attached application fails when executed using bfin-elf-run. It gives a return code of 1.

When loaded and executed under bfin-elf-gdb, the applications fails the first time exiting with a code of 01. Further runs of the application under bfin-elf-gdb (without restarting the debugger) result in the application executing as expected:

 

$ bfin-elf-c++ -g init18.C -o init18.dxe -msim

$ bfin-elf-run init18.dxe

$ echo $?

1

 

Under gdb, the test should hit a breakpoint at init18.C:21 - The destructor for Foo2. This does not occur on the first execution:

 

% bfin-elf-gdb init18.dxe

(gdb) target sim

Connected to the simulator.

(gdb) load init18.dxe

Loading section .init, size 0x12 lma 0x0

Loading section .text, size 0x9728 lma 0x14

Loading section .fini, size 0xe lma 0x973c

Loading section .rodata, size 0x1a28 lma 0x974c

Loading section .eh_frame, size 0xa40 lma 0xb174

Loading section .gcc_except_table, size 0xb8 lma 0xbbb4

Loading section .ctors, size 0xc lma 0xcc6c

Loading section .dtors, size 0x8 lma 0xcc78

Loading section .jcr, size 0x4 lma 0xcc80

Loading section .data, size 0x820 lma 0xcc84

Start address 0x14

Transfer rate: 402688 bits in <1 sec.

(gdb) break init18.C:21

Breakpoint 1 at 0x288: file init18.C, line 21.

(gdb) break _exit

Breakpoint 2 at 0x9434: file /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/libgloss/bfin/syscalls.c, line 35.

(gdb) break __call_exitprocs

Breakpoint 3 at 0x86b4: file /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/newlib/libc/stdlib/__call_atexit.c, line 18.

(gdb) run

Breakpoint 3, __call_exitprocs (code=1, d=0x0) at /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/newlib/libc/stdlib/__call_atexit.c:18

(gdb) cont

Continuing.

Breakpoint 2, _exit (n=1) at /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/libgloss/bfin/syscalls.c:35

35        register int r asm ("P0") = reason;

(gdb) cont

Continuing.

Program exited with code 01.

 

 

And then re-running the application:

(gdb) run

Starting program: /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/gcc/testsuite/g++.old-deja/g++.other/init18.dxe

 

Breakpoint 3, __call_exitprocs (code=1, d=0x0) at /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/newlib/libc/stdlib/__call_atexit.c:18

18      {

(gdb) cont

Continuing.

Breakpoint 1, ~Foo2 (this=0xd4cc) at init18.C:21

21                      ~Foo2() { if (++cnt == 2) _exit (0); }

Current language:  auto; currently c++

(gdb) cont

Continuing.

Breakpoint 2, _exit (n=0) at /home/dgibso2/gnu_work/checkouts/toolchain/gcc-4.3/libgloss/bfin/syscalls.c:35

35        register int r asm ("P0") = reason;

Current language:  auto; currently c

(gdb) cont

Continuing.

 

Program exited normally.

 

 

I would have expected the application to have exited normally.

 

The issue came about as part of the investigation for issue 6095.

 

Follow-ups

 

--- Mike Frysinger                                           2010-09-08 11:32:43

memory is not cleared (.bss) when you simply re-run.  i'm not sure if it is even

re-initialized (.data).

 

--- David Gibson                                             2010-09-09 04:36:22

Ah I didn't realise that.

Is there a clean way to reset the simulator under GDB?

The only way I have found so far, other than exiting and restarting GDB, is to

issue the commands:

 

target sim

load <app>

 

My application again fails, which suggests it has disconnected the sim,

reconnected starting afresh. Is this a safe/correct way to reset the sim?

 

--- Mike Frysinger                                           2010-09-09 12:41:30

"target sim" will reset all the memory to 0 (a clean slate).

"load" will reset the sections that the app loads (like .data/.text).

 

so what you're after is that set of two commands.

 

--- David Gibson                                             2010-09-13 06:40:58

Closed. Not a bug. As Mike points out, to reset the simulator session under GDB,

you need to issue target sim/load app to ensure all memory is reset to its

initial state.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes