How to setup a conditional breakpoint with simics command? - simics

It looks like Simics Eclipse can setup a conditional breakpoint, but I didn't find any condition parameters with break-* commands. Is that possible to setup the break condition with simics commands?
Another question is how can I setup dynamic printf with simics commands?
with gdb, I can use this to logging breakpoint hits, how can I do the same thing with simics?
(gdb) b malloc
(gdb) commands
> silent
> printf "malloc hit"
> cont
> end
(gdb)


Simics does not have conditional breakpoints in the built-in breakpoint commands. If you want to do something like that, write a script branch that waits for the breakpoint and then inspect the state. The commands are intentionally fairly basic.
What is a "dynamic printf" in this context?
It might be simpler to use Simics gdb-remote to connect a gdb debugger to Simics and use that to debug your target software.
To see all breakpoint hits, Simics will tend to write a message each time the breakpoint hit:
simics> bp.memory.break -x 0xffff0000 0x100000
Breakpoint 2: break on 'x' access to 0xffff_0000 len=1_048_576 in board.cell_context
simics> r
[board.cell_context] Breakpoint 2: board.cell_context 'x' access to v:0xfffffff0
simics> r
[board.cell_context] Breakpoint 2: board.cell_context 'x' access to v:0xfffffff1
simics> r
[board.cell_context] Breakpoint 2: board.cell_context 'x' access to v:0xfffffff2 len=2
If you want to act on a breakpoint hit, use a script to react and print whatever your want. Like this, for example. If a script branch picks up the breakpoint, Simics will not stop its execution.
simics> script-branch {
....... while(TRUE) {
....... bp.wait-for-breakpoint 2
....... echo (ptime)
....... }
....... }
2
simics> r
"board.mb.cpu0.core[0][0]"
[["board.mb.cpu0.core[0][0]", 8, 8, 4e-09]]
"board.mb.cpu0.core[0][0]"
[["board.mb.cpu0.core[0][0]", 9, 9, 4.5e-09]]
"board.mb.cpu0.core[0][0]"

Related

OpenOCD exit on breakpoint

I'm developing an application on an STM32F042.
I drive everything from a makefile, including my unit tests.
I use OpenOCD and ST-LINK to flash the target.
My unit tests run on the host and on the target.
The host unit test driver returns 0 from main() on success and non-zero on failure, so the makefile knows if the tests pass.
The makefile flashes and starts tests on the target, but doesn't know if they succeed or fail.
The embedded test application turns on a red LED for fail and green for pass, so I know--now I want to automate this step.
I want to set two breakpoints in the code, one in the failure handler and one at the end of main, and tell OpenOCD to exit with zero or non-zero status if it hits one or the other breakpoint.
So my question boils down to two specific ones:
To set a breakpoint, I need to know the PC value at a specific line of code. How do I get that value from the arm-gcc toolchain?
Can I configure OpenOCD to exit on specific breakpoints, and with specific status?

Here's what I ended up with. For each target unit test, I start an OpenOCD server and connect to it with gdb. Gdb runs a script that sets two breakpoints, one for success, one for failure. If it hits either breakpoint, it shuts down the OCD server and exits with a code that communicates success and failure to the shell. To run the same tests on the host, I simply compile them as regular executables.
Makefile:
# target unit test binaries
foo_tests.elf bar_tests.elf baz_tests.elf bop_tests.elf: unit_test_runner.ao
# disable optimization for target unit test driver to avoid optimizing
# away functions that serve as breakpoint labels
unit_test_runner.ao: CFLAGS += -O0 -g
# link target unit test binaries for semihosting
%_tests.elf: ARM_LDLIBS += -specs=rdimon.specs -lrdimon
# host unit test binaries
foo_tests bar_time_tests baz_tests bop_tests: unit_test_runner.o
# run target unit test binaries through gdb and OpenOCD; redirecting stderr
# leaves printf output from `assert()' clearly visible on the console
%.tut: %.elf
openocd -f interface/stlink-v2-1.cfg -f target/stm32f0x.cfg 2> $#.log &
gdb-multiarc -batch-silent -x tut.gdb $< 2> $#-gdb.log
# run host binary
%.run: %
./$*
tests: foo_tests.run bar_time_tests.run baz_tests.run bop_tests.run \
foo_tests.tut bar_time_tests.tut baz_tests.tut bop_tests.tut
tut.gdb:
target remote localhost:3333
monitor arm semihosting enable # let assert()'s printf() through
monitor reset halt
load
monitor reset init
break success # set breakpoint on function `sucess()'
commands # on hitting this bp, execute the following:
monitor shutdown # shutdown OpenOCD server
quit 0 # exit GDB with success code
end
break failure # set breakpoint on function `sucess()'
commands
monitor shutdown
quit 1 # exit GDB with failure code
end
continue
unit_test_runner.c:
#include <stdlib.h>
/* These two functions serve as labels where gdb can place
breakpoints. */
void success() {}
void failure() {}
/* Implementation detail for `assert()' macro */
void assertion_failure(const char *file,
int line,
const char *function,
const char *expression)
{
printf("assertion failure in %s:%d (%s): `%s'\n",
file, line, function, expression);
failure();
exit(1);
}
/* This function is necessary for ARM semihosting */
extern void initialise_monitor_handles(void);
int main(int argc, char* argv[])
{
#ifdef __arm__
initialise_monitor_handles();
#endif
tests(); /* client code implements this function */
success();
return 0;
}

Julia, handle keyboard interrupt

Title says it all. How can I handle or catch a SIGINT in julia? From the docs I assumed I just wanted to catch InterruptException using a try/catch block like the following
try
while true
println("go go go")
end
catch ex
println("caught something")
if isa(ex, InterruptException)
println("it was an interrupt")
end
end
But I never enter the catch block when I kill the program with ^C.
edit: The code above works as expected from the julia REPL, just not in a script.

I see the same behavior as alto, namely that SIGINT kills the entire process when my code is run as a script but that it is caught as an error when run in the REPL. My version is quite up to date and looks rather similar to that of tholy:
julia> versioninfo()
Julia Version 0.3.7
Commit cb9bcae* (2015-03-23 21:36 UTC)
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-3610QM CPU # 2.30GHz
WORD_SIZE: 64
BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
Digging through the source, I found hints that Julia's interrupt behavior is determined by an jl_exit_on_sigint option, which can be set via a ccall. jl_exit_on_sigint is 0 for the REPL, but it looks as if init.c sets it to 1 when running a Julia program file from the command line.
Adding the appropriate ccall makes alto's code works regardless of the calling environment:
ccall(:jl_exit_on_sigint, Void, (Cint,), 0)
try
while true
println("go go go")
end
catch ex
println("caught something")
if isa(ex, InterruptException)
println("it was an interrupt")
end
end
This does seem to be a bit of a hack. Is there a more elegant way of selecting the interrupt behavior of the environment? The default seems quite sensible, but perhaps there should be a command line option to override it.

For julia >= 1.5, there is Base.exit_on_sigint. From the docs (retrieved on 20220419)
Set exit_on_sigint flag of the julia runtime. If false, Ctrl-C (SIGINT) is capturable as InterruptException in try block. This is the default behavior in REPL, any code run via -e and -E and in Julia script run with -i option.

Works for me. I'm running
julia> versioninfo()
Julia Version 0.3.0-prerelease+695
Commit 47915f3* (2013-12-27 05:27 UTC)
DEBUG build
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7 CPU L 640 # 2.13GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
LAPACK: libopenblas
LIBM: libopenlibm
but I expect it's not necessary to be fully up-to-date for this to work (I'd guess 0.2 should be fine too).

WinDbg: using commands for the condition in .if

WinDbg has the .if statement for conditional execution of commands:
.if (Condition) { Commands } .else { Commands }
For Condition, it's not possible to use WinDbg commands. Is there any indirect way of using commands for the condition, e.g. through pseudo registers?
Example task to accomplish:
If a logfile is already opened, do nothing. If no logfile is open, use .logopen /t /u /d
With .logfile, I can find out whether a log is open or not. But how to parse that output and how to assign the result to a pseudo register?
Any other way without pseudo registers is also welcome.
As the example may not seem very useful, consider the following tasks which can be automated by scripting or the .cmdtree window:
Loading the correct version of SOS, e.g. .if (lm m clr == clr) { .loadby sos clr } .elseif (lm m mscorwks == mscorwks) {.loadby sos mscorwks}
Things I always forget to do, e.g. .if (| == myprocess) {.childdbg 1; .sympath+ mydir}

I tested this and it loads the correct sos.dll if it finds clr in the list of modules:
.foreach (module {lm1m} ) { .if ($sicmp("${module}","clr") == 0) {.echo FOUND ${module}; .loadby sos.dll clr} }
You can easily extend it using .elsif and comparing module with "mscorwks".
As for checking for your process, I attached to calc.exe and ran | which gives me: . 0 id: 6bc attach name: C:\Windows\system32\calc.exe
I only want the last token so I can skip the first six by specifying /pS 6 to .foreach. The following uses a wildcard comparison for *calc.exe and if found, tells the debugger to debug child processes:
.foreach /pS 6 (token {|}) {.echo ${token}; .if($spat("${token}","*calc.exe") == 1) {.echo FOUND MY APP;.childdbg 1} .else {.echo FAILED TO FIND MY APP} }
Also tested and worked.
ps. my debugger version is 6.2.8400.0

Using devenv to pass preprocessor variables to Intel Fortran compiler

I'm using VS 2008 with Intel(R) Fortran Compiler version 10.1.025.
To build my solution I'm using a batch file with the following syntax:
devenv /rebuild "Release|Win32" "c:...\solution.sln" /Project "ProjectName_InTheSolution"
Using the configuration "Release|Win32" I specify, in VS ProjectProperties->Fortran->Proprocessor->Preprocessor Definitions the value "test".
Inside my code I'm testing if the "test" variable is define which is working everything correctly.
Any one know any way to change the "Preprocessor Definitions" of the fortran compiler using the command line ? I want to add also the value "commandLine" so would be "test;commandline" in the "Preprocessor Definitions".
Some notes:
1) I have to use the devenv.exe
2) I don't want to change neither the source code or the project file prior the compilation
3) I can use environment variable to pass option (if there is any way, I try the CL but didn't work)
Thanks in advance
Thanks for your answer but maybe I didn't understand completely your solution, but this is what I tried:
1)I change the "Additional Options" (AO) to /Dtest and:
1.1) If I compile from the Visual Studio or Command Line the check "!DEC$ IF DEFINED (test)" is true
2)I changed the AO to "$(DEFINE)" and:
2.1) From Visual Studio I see warnings: "command line warning #10161: unrecognized source type '$(DEFINE)'; object file assumed ifort " and the check "!DEC$ IF DEFINED (test)" is false
2.2) I add the Define variable to "User environment variables", same error from 2.1
3) I change the AO to "/D$(DEFINE)" I got an error "Bad syntax, '=' expected while processing '#$(define)' fortcom "
4) I change the AO to "$(DEFINE)" and SET DEFINE=/test, and didn't work either, the "!DEC$ IF DEFINED (test)" is false
#cup I think I need to understand a little better your solution, if you please could give me an additional information about your solution would be very appreciated.
What I'm trying to do is this:
program main
integer:: ii
!DEC$ IF DEFINED (test)
ii = 72
!DEC$ ENDIF
!DEC$ IF DEFINED (test2)
ii = 80
!DEC$ ENDIF
print *, "this is up to column ", ii
end
Now I want to control from the command line which part of code will be compiled, doing something like this:
1) from the command line: set define=test
2) devenv elephant.sln /build
3) run debug/elephant.exe -> get "72"
4) from the command line: set define=test2
5) devenv elephant.sln /build
6) run debug/elephant.exe -> get "80"
This is possible ?
Thanks in advance,
rui

Try this
1) Create the following F77 program
program main
integer:: ii
! ,-- column 73
ii = 72 +8
print *, "this is up to column ", ii
end
2) Create a solution for the above program, say elephant.sln
If you just build and run, it should display "this is up to column 72"
3) Pop up project properties, under Fortran/Command Line, add $(DEFINES) in the Additional Options Box.
4) Save and exit
5) set DEFINES=/extend_source:72
6) devenv elephant.sln /build
7) run debug/elephant.exe - you should get 72
8) set DEFINES=/extend_source:80
9) devenv elephant.sln /build
10) run debug/elephant.exe - you should get 80.
11) If you wish to add more /D options, stick it in the DEFINES environment variable.
Basically don't use preprocessor defines - just dump your settings into the DEFINES environment variable and it will be picked up by the Additional Options.

iPhone Dev: Xcode debugger does not stop on breakpoints

I've got Xcode 3.1.2 on OS X 10.5.5. I have an iPhone project that builds fine but the debugger will not hit any of the breakpoints I set. I've tried all the standard fixes that I find on the net:
I've turned off 'Load Symbols Lazily' in Xcode preferences
My active config is Debug
Optimization level is 0 in build settings
I've cleaned all targets and rebuilt
I use Build and Debug (as opposed to Build and Run)
I thought I might have inadvertently tweaked settings on my project. So I created a new project and that one has the same problem.
I'm hoping that I am missing something easy here. My debugger was working just a few days back but all of a sudden it has stopped.
UPDATE:
Things are just getting stranger. Here are some answers to the responses
I cannot find 'GCC 4.0 - Code Generation' options anywhere. I've looked hi and low in both Target and Executable Info pages. The only option I see is to select the compiler version, and GCC 4.0 is selected, but that is a one-line section with no additional options.
About where to put breakpoints: My only breakpoint for now is in main(), and it is not being hit
I am starting the debugger with the Run -> Debug (/% Y) command. Still no luck
UPDATE 2:
Changed Base SDK in target settings to Sim 2.2.1. Changed Active SDK to Sim 2.2.1.
Now I can see GCC 4.0 Code Generation options - Debug Symbols are checked
Still does not hit breakpoints
here is the Console log (breakpoint set at first line of main.m):
[Session started at 2009-03-06 21:29:19 -0600.]
Loading program into debugger…
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 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 "i386-apple-darwin".warning: Unable to read symbols for "/System/Library/Frameworks/UIKit.framework/UIKit" (file not found).
warning: Unable to read symbols from "UIKit" (not yet mapped into memory).
warning: Unable to read symbols for "/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics" (file not found).
warning: Unable to read symbols from "CoreGraphics" (not yet mapped into memory).
Program loaded.
sharedlibrary apply-load-rules all
Attaching to program: `/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/753D12B3-777C-473B-B098-3E0AF6282545/TestApp.app/TestApp', process 577.
Re-enabling shared library breakpoint 1
Also is here the gdb log:
t=0.000852 Tepoch=1236463545.631514
<- (gdb)
-> 135-gdb-version
# PBXGDB_MIGDBVersionCommand t=4.308986 Tepoch=1236463549.939648
-> 136-gdb-set auto-raise-load-levels 1
# PBXGDB_MISetAutoRaiseSymbols t=4.309420 Tepoch=1236463549.940082
-> 139-gdb-set env __CF_USER_TEXT_ENCODING 0x0:0:0
# PBXGDB_MISetEnvCommand t=4.309702 Tepoch=1236463549.940364
-> 140-gdb-set env USERBREAK 1
# PBXGDB_MISetEnvCommand t=4.309935 Tepoch=1236463549.940598
-> 141-gdb-set env DYLD_FRAMEWORK_PATH /Projects/TestApp/build/Debug-iphonesimulator
# PBXGDB_MISetEnvCommand t=4.310175 Tepoch=1236463549.940837
-> 142-gdb-set env Apple_PubSub_Socket_Render /tmp/launch-GqkpX5/Render
# PBXGDB_MISetEnvCommand t=4.310568 Tepoch=1236463549.941231
-> 143-gdb-set env SECURITYSESSIONID 715cd0
# PBXGDB_MISetEnvCommand t=4.310803 Tepoch=1236463549.941465
-> 144-gdb-set env DYLD_LIBRARY_PATH /Projects/TestApp/build/Debug-iphonesimulator
# PBXGDB_MISetEnvCommand t=4.311040 Tepoch=1236463549.941702
-> 145-gdb-set env SSH_AUTH_SOCK /tmp/launch-hRgLzb/Listeners
# PBXGDB_MISetEnvCommand t=4.311299 Tepoch=1236463549.941961
-> 146-gdb-set env HOME /var/root
# PBXGDB_MISetEnvCommand t=4.311587 Tepoch=1236463549.942250
-> 147-gdb-set env SHELL /bin/sh
# PBXGDB_MISetEnvCommand t=4.311818 Tepoch=1236463549.942480
-> 148-gdb-set env DYLD_NO_FIX_PREBINDING YES
# PBXGDB_MISetEnvCommand t=4.312048 Tepoch=1236463549.942710
-> 149-gdb-set env COMMAND_MODE unix2003
# PBXGDB_MISetEnvCommand t=4.312281 Tepoch=1236463549.942943
-> 150-gdb-set env DYLD_NEW_LOCAL_SHARED_REGIONS YES
# PBXGDB_MISetEnvCommand t=4.312546 Tepoch=1236463549.943209
-> 151-gdb-set env SSH_ASKPASS /Developer/Library/PrivateFrameworks/DevToolsInterface.framework/Resources/Xcode SSHPassKey
# PBXGDB_MISetEnvCommand t=4.312780 Tepoch=1236463549.943443
-> 152-gdb-set env PATH /Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
# PBXGDB_MISetEnvCommand t=4.313612 Tepoch=1236463549.944275
-> 153-gdb-set env DISPLAY /tmp/launch-yrv3vV/:0
# PBXGDB_MISetEnvCommand t=4.313849 Tepoch=1236463549.944512
-> 154-gdb-set env USER root
# PBXGDB_MISetEnvCommand t=4.314141 Tepoch=1236463549.944803
-> 155-gdb-set env NSUnbufferedIO YES
# PBXGDB_MISetEnvCommand t=4.314377 Tepoch=1236463549.945039
# Enqueue seq in Command Q: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.314625 Tepoch=1236463549.945288
# Executing Sequence: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.314718 Tepoch=1236463549.945380
-> 157-gdb-set inferior-auto-start-cfm off
# PBXGDB_MISetLoadCFMInfoCommand t=4.314895 Tepoch=1236463549.945557
-> 156-gdb-set sharedLibrary load-rules dyld ".*Foundation.*" all dyld ".*libobjc.*" all dyld ".*libauto.*" all dyld ".*/usr/lib/dyld.*" all dyld ".*CFDataFormatters.*" all dyld ".*PBGDBIntrospectionSupport.*" all dyld ".*AppKit.*" all dyld ".*libSystem.*" all dyld ".*CarbonDataFormatters.*" all dyld ".*CoreFoundation.*" extern dyld "/System/Library/Frameworks\\\\|/System/Library/PrivateFrameworks\\\\|/usr/lib" extern dyld ".*" extern exec ".*" extern
# PBXGDB_MISetSharedLibraryLoadSymbolsCommand t=4.315975 Tepoch=1236463549.946637
-> 137-file-exec-and-symbols "/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp"
# PBXGDB_MILoadExecutableCommand t=4.320612 Tepoch=1236463549.951275
# Enqueue seq in Command Q: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.321476 Tepoch=1236463549.952138
# Enqueue seq in Command Q: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.321941 Tepoch=1236463549.952603
# Enqueue seq in Command Q: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=4.322157 Tepoch=1236463549.952820
<- ~"GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)\n"
<- ~"Copyright 2004 Free Software Foundation, Inc.\n"
<- ~"GDB is free software, covered by the GNU General Public License, and you are\nwelcome to change it and/or distribute copies of it under certain conditions.\nType \"show copying\" to see the conditions.\nThere is absolutely no warranty for GDB. Type \"show warranty\" for details.\n"
<- ~"This GDB was configured as \"i386-apple-darwin\"."
<- 135^done,version="6.3.50-20050815 (Apple version gdb-962)",rc_version="962",target="i386-apple-darwin",build-date="Sat Jul 26 08:14:40 UTC 2008",time={wallclock="0.03311",user="0.00081",system="0.00014",start="1236463549.989179",end="1236463550.022291"}
# processing result t=4.392345 Tepoch=1236463550.023007
<- (gdb)
<- 136^done,time={wallclock="0.00005",user="0.00005",system="0.00001",start="1236463550.024272",end="1236463550.024325"}
# processing result t=4.394163 Tepoch=1236463550.024826
<- (gdb)
<- 139^done,time={wallclock="0.00007",user="0.00005",system="0.00002",start="1236463550.025511",end="1236463550.025581"}
# processing result t=4.395347 Tepoch=1236463550.026010
<- (gdb)
<- 140^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.026564",end="1236463550.026597"}
# processing result t=4.396328 Tepoch=1236463550.026991
<- (gdb)
<- 141^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.027857",end="1236463550.027890"}
# processing result t=4.397653 Tepoch=1236463550.028315
<- (gdb)
<- 142^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.029080",end="1236463550.029113"}
# processing result t=4.398865 Tepoch=1236463550.029528
<- (gdb)
<- 143^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.030126",end="1236463550.030159"}
# processing result t=4.399923 Tepoch=1236463550.030585
<- (gdb)
<- 144^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.031449",end="1236463550.031482"}
# processing result t=4.401855 Tepoch=1236463550.032518
<- (gdb)
<- 145^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.033257",end="1236463550.033291"}
# processing result t=4.403022 Tepoch=1236463550.033685
<- (gdb)
<- 146^done,time={wallclock="0.00006",user="0.00003",system="0.00002",start="1236463550.034226",end="1236463550.034287"}
# processing result t=4.404018 Tepoch=1236463550.034680
<- (gdb)
<- 147^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.035215",end="1236463550.035247"}
# processing result t=4.405007 Tepoch=1236463550.035670
<- (gdb)
<- 148^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.036306",end="1236463550.036340"}
# processing result t=4.406068 Tepoch=1236463550.036731
<- (gdb)
<- 149^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.037344",end="1236463550.037377"}
# processing result t=4.407107 Tepoch=1236463550.037770
<- (gdb)
<- 150^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.038448",end="1236463550.038483"}
# processing result t=4.408214 Tepoch=1236463550.038876
<- (gdb)
<- 151^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.040541",end="1236463550.040576"}
# processing result t=4.410438 Tepoch=1236463550.041101
<- (gdb)
<- 152^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.041901",end="1236463550.041933"}
# processing result t=4.411665 Tepoch=1236463550.042327
<- (gdb)
<- 153^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.042984",end="1236463550.043016"}
# processing result t=4.412784 Tepoch=1236463550.043446
<- (gdb)
<- 154^done,time={wallclock="0.00003",user="0.00002",system="0.00001",start="1236463550.043956",end="1236463550.043988"}
# processing result t=4.413717 Tepoch=1236463550.044379
<- (gdb)
<- 155^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.044974",end="1236463550.045007"}
# processing result t=4.414737 Tepoch=1236463550.045400
<- (gdb)
<- 157^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.046108",end="1236463550.046141"}
# processing result t=4.415931 Tepoch=1236463550.046594
<- (gdb)
<- 156^done,time={wallclock="0.00005",user="0.00005",system="0.00001",start="1236463550.050271",end="1236463550.050324"}
# processing result t=4.420235 Tepoch=1236463550.050897
-> 158sharedlibrary apply-load-rules all
# PBXGDB_MISharedLibraryApplyLoadRulesCommand t=4.420386 Tepoch=1236463550.051049
<- (gdb)
<- &"warning: Unable to read symbols for \"/System/Library/Frameworks/UIKit.framework/UIKit\" (file not found).\n"
<- &"warning: Unable to read symbols from \"UIKit\" (not yet mapped into memory).\n"
<- &"warning: Unable to read symbols for \"/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics\" (file not found).\n"
<- &"warning: Unable to read symbols from \"CoreGraphics\" (not yet mapped into memory).\n"
<- 137^done,time={wallclock="0.34917",user="0.17115",system="0.11409",start="1236463550.052577",end="1236463550.401747"}
# processing result t=4.771918 Tepoch=1236463550.402580
<- (gdb)
<- &"sharedlibrary apply-load-rules all\n"
<- 158^done
# processing result t=4.820019 Tepoch=1236463550.450681
# didFinish Sequence: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.820135 Tepoch=1236463550.450797
# Executing Sequence: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.820259 Tepoch=1236463550.450921
-> 159-mi-verify-command file-fix-file-is-grooved
# PBXGDB_MIVerifyCommandCommand t=4.820398 Tepoch=1236463550.451060
<- (gdb)
<- 159^done,name="file-fix-file-is-grooved",defined="true",implemented="true",time={wallclock="0.00011",user="0.00007",system="0.00001",start="1236463550.451848",end="1236463550.451955"}
# processing result t=4.821746 Tepoch=1236463550.452409
-> 160-file-fix-file-is-grooved
# PBXGDB_MIFixAndContinueSupportedCommand t=4.821894 Tepoch=1236463550.452556
<- (gdb)
<- 160^done,supported="1",details="Yes grooved!",time={wallclock="0.00006",user="0.00005",system="0.00002",start="1236463550.453356",end="1236463550.453417"}
# processing result t=4.823203 Tepoch=1236463550.453865
# didFinish Sequence: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.823344 Tepoch=1236463550.454006
# Executing Sequence: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.823433 Tepoch=1236463550.454095
# Passed verification of state before break create command t=4.823569 Tepoch=1236463550.454231
-> 161-break-insert -l -1 -f -s "TestApp" "\"main.m:13\""
# PBXGDB_MICreateFileBreakpointCommand t=4.823679 Tepoch=1236463550.454342
<- (gdb)
<- =shlib-state-modified,shlib-info=[num="1",name="TestApp",kind="-",dyld-addr="-",reason="exec",requested-state="Y",state="Y",path="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",description="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",loaded_addr="",slide="0x0",prefix="",dsym-objpath="/Projects/TestApp/build/Debug-iphonesimulator/TestApp.app.dSYM/Contents/Resources/DWARF/TestApp"]
<- 161^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000028cf",func="main",file="/Projects/TestApp/main.m",line="13",shlib="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",times="0"},time={wallclock="0.15835",user="0.00321",system="0.00184",start="1236463550.455187",end="1236463550.613542"}
# processing result t=4.996437 Tepoch=1236463550.627100
# didFinish Sequence: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.996599 Tepoch=1236463550.627262
# Executing Sequence: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=4.996690 Tepoch=1236463550.627352
-> 162-mi-verify-command target-attach
# PBXGDB_MIVerifyCommandCommand t=4.996824 Tepoch=1236463550.627486
<- (gdb)
<- 162^done,name="target-attach",defined="true",implemented="true",time={wallclock="0.00007",user="0.00006",system="0.00001",start="1236463550.627975",end="1236463550.628046"}
# processing result t=4.998137 Tepoch=1236463550.628799
-> 163-target-attach 288
# PBXGDB_MIAttachCommand t=4.998293 Tepoch=1236463550.628955
<- (gdb)
<- ~"Attaching to program: `/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp', process 288.\n"
<- ~"Re-enabling shared library breakpoint 1\n"
<- =shlibs-updated
<- 163^done,thread-id="1",time={wallclock="0.00362",user="0.00151",system="0.00203",start="1236463550.629436",end="1236463550.633055"}
# processing result t=5.010455 Tepoch=1236463550.641117
# Enqueue seq in Command Q: <PBXGDB_ThreadListSequence: 0xa4e0520> t=5.011284 Tepoch=1236463550.641946
-> 164-exec-continue
# PBXGDB_MIContinueExecutableCommand t=5.011420 Tepoch=1236463550.642082
<- (gdb)
<- 164^running
# processing result t=5.070065 Tepoch=1236463550.700727
# didFinish Sequence: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=5.071843 Tepoch=1236463550.702505
<- (gdb)

I cannot find 'GCC 4.0 - Code
Generation' options anywhere. I've
looked hi and low in both Target and
Executable Info pages. The only option
I see is to select the compiler
version, and GCC 4.0 is selected, but
that is a one-line section with no
additional options.
That's an Xcode bug in 3.1.1 and 3.1.2 if the Active SDK is out of synch with the target's Base SDK. Set the Target's Base SDK to Simulator, make sure your Active SDK is Simulator, and try again.
If you really want this answered, you're going to have to post more information about your project: a screen shot of the Build Settings, or text from the Debugger Console.
UPDATED:
Also note in Xcode > Preferences > Debugging:
alt text http://idisk.mac.com/cdespinosa/Public/GDB%20Log.png
Check the box, enter a reasonable path into the path field, try your debug scenario, then file a bug at http://bugreporter.apple.com with the log attached and a description of your scenario, or ask the good people over at xcode-users#lists.apple.com. The gdb log contains all the information about how the debugger is interacting with your application.

In the Xcode preferences go into the debugging section and turn off 'Load symbols lazily'.
That fixed it for me a few months ago when I first run into this problem.

This is sort of a "is it plugged in" answer, but hey, sometimes that is the problem: Are breakpoints enabled? Sometimes when I debug, I forget to click the button in the debugging toolbar that enables and disables breakpoints.

The GCC 4.0 - Code Generation section only shows up when you set the Active SDK to Device - iPhone OS 2.x. Go figure. They disappear when the Active SDK is the simulator.
You should change your Active SDK to Device, change the settings, and then change back to Simulator. The settings made under Device should also hold for Simulator. This also works with eg. setting a -DDEBUG flag for preprocessing.
(Update: I was only half right. See Chris Espinosa's accepted answer re: this SDK bug. It's not that the GCC 4.0 section shows up when the Active SDK is set to "Device," it's that your Base SDK and Active SDK must match up to access these settings).

Another simple suggestion:
Are the breakpoints light blue are dark blue?
Xcode allows you to deactivate breakpoints and these are indicated with a light blue arrow (like it has been dimmed).

Try running the project by hitting Command-Option-Y (this forces Xcode to start the program with the debugger).
The buttons on the menu bar of Xcode can be somewhat misleading. If the button says 'Run', it doesn't run the program in the debugger. If it says 'Go' it runs the program however it was last built (ie release or debug). Command-Option-Y starts the program specifically in the debugger.
Also, make sure your breakpoints are enabled. You can right click on them to check. Also, in the Debugger window, there should be an option on the toolbar for Activate or Deactivate Breakpoints. Make sure they're activated.

This may be an exceptionally obvious answer, but it could work. Have you tried adding breakpoints in code other than main() ? For instance, in the App Delegate's applicationDidFinishLaunching method? I know it SHOULD go through main first, but since that code in main is not normally modified for iPhone apps, it might be a bit flaky. It's worth a try, anyway.
Also, to find the GCC 4.0 - Code Generation options, click the triangle to open the Targets group, and click on your app's name underneath Targets. Click on the Info button up in the top of the Xcode window and you'll get the settings for your app. Go to Build. Make sure the Show: dropdown is set to All Settings. If you scroll down from there, it should be one of the lists you can edit (after Versioning and before GCC 4.0 - Language)

When the program is running, can you do a CTRL-C in the Console window (while cursor is there). If you interrupt the program type info br which should give a list of the active breakpoints, question then is, are they what you set?

There are two gdb configuration files that can be good to have a look at.
/etc/gdb.conf
Mine have MD5 (/etc/gdb.conf) = 31b58e1ecf038554faadf777d63e9085
~/.gdbinit
I have no, do you have one?

Have you verified that your build configuration is using your development certificate for code signing?
If you are using an Ad Hoc certificate, it'll still build and run fine, but shortly after launching the app, Xcode will detach from the device so no breakpoints will ever hit. You can quickly tell whether it has detached or not if you look in the bottom left of the main Xcode window after you've clicked Build & Go - if you aren't using the actual development device certificate, you'll see a message that says something like "Invalid Hex Code Received from Device".

I looks like you are running the program as root, that doesn't seem to be right...

In your build setting list, you don't cover the most crucial one:
alt text http://idisk.mac.com/cdespinosa/Public/Generate%20Debug%20Symbols.png
Make sure Generate Debug Symbols is checked for the Debug configuration, and make sure that the Debug configuration is active when you Build and Debug.
Two other things to try:
1) Uncheck Fix and Continue. Your detailed gdb log indicates that it may be on. Make sure you are looking at the target settings and not the project settings when confirming this.
2) Try not running as root. It's unclear why you need to. It is possible that Xcode running as root has interactions with the simulator; frankly we don't use that configuration much so I wouldn't know.
The log shows everything operating pretty normally. You have a built binary that's being launched in the Simulator; it's the right architecture and well-formed; you have debug symbols; you have a breakpoint, and the breakpoint is being set. We're taking your word for it (as we don't see your source) that the breakpoint is actually on a line of code that is being executed.

If you are using an Ad Hoc certificate, it'll still build and run fine, but shortly after
launching the app, Xcode will detach from the device so no breakpoints will ever hit.
This helped me.

I have to ask, as I had the same problem, is this a 'real' mac? There is this exact problem with the voodoo hacintosh kernal. If you are using the voodoo kernal, boot with std_dyld=1 and all will be well

This really works on voodoo kernel, booting with std_dyld=1 make Xcode stop at breakpoint. Amazing tip, really. Many thanks to you John your a kind of life saver !!!
I used OSX86Tools to add this boot flag automatically.
Polo

I tried pretty much everything in this thread and restarting the device solved my problem.

I just had the same problem. I don't have a real solution yet, but I figured out, that in my case it is device dependent. The error only happens on my iPod Touch 4G. When I switch to my iPhone 3G, everything works fine and the breakpoints work again.
I don't know if this has anything to do with the problem, but may be the iPod4 has problem due to the installed iOS 5 beta 2. Usually when I encounter a bug in iOS 5 it's fine to just reboot the device. However... rebooting the iPod4 didn't help in my case...
Solution:
This problem bugged me now for some weeks, but I finally found a solution for my case:
Make sure the SDK on your Mac is the same (or newer) as the iOS version on your device.
Reboot the device while it is connected via USB and Xcode is running.

I had a similar situation.. after 6 hours of debugging and project file comparison, it finally worked. The situation was I had a 2 year old project originally made in Xcode 3.1 days. I tried to run it in Xcode 4.5.1 with breakpoints and it never worked.
Here is what I did to fix it..
1) In the Project>Build Settings.. Search for Debug.
2) Build active Architecture only > Change Debug to Yes
3) Generate Debug Symbols > Yes
4) Preprocessor Macros > Debug = 1
It runs fine now.

Apple should really improve the overall Xcode experience. I understand its free (hey, you get what you pay for), but still, the bugs in it is almost insulting to developers.