Unable to Resolve Breakpoints in C files Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Unable to Resolve Breakpoints in C files

Post by aneves »

I am playing around with the AN00135 Test and Measurement Class demo provided by xTIMEcomposer 14. This example uses a C library which is responsible for parsing SCPI commands sent by the host to the device.

The problem I have is that I am unable to place a breakpoint in any of the C files in the project. To be more specific, I can add a breakpoint in a C file while in the edit perspective. However, once I click on the Debug button and switch over to the debug perspective, I get the yellow triangle with an exclamation mark telling me that it is an unresolved breakpoint. The same thing happens if I try to add a breakpoint to a C file while debugging is currently taking place too.

I can place breakpoints in any xc file and those will get resolved by the debugger. I can also step into the C library after breaking on the caller that resides in an xc file. However, there are times I would like to break on a very specific location that are a few levels deep and having to always step into the location of interest at such a high level is cumbersome. The fact that I can eventually step into the C library gives me a clue that debugging info for the C modules are being created, but the debugger perspective does not resolve it for some reason.

Below is my MakeFile. You'll notice that it is basically the same one that is provided with the example except that I've stripped out sections that do not apply to my board and I have removed optimization and added "-g" to produce the debugging info.

Code: Select all

# The TARGET variable determines what target system the application is
# compiled for. It either refers to an XN file in the source directories
# or a valid argument for the --target option when compiling.

# In this case, the target depends on the build configuration.
TARGET = XUE216-512-TQ128-C20

# The APP_NAME variable determines the name of the final .xe file. It should
# not include the .xe postfix. If left blank the name will default to
# the project name
APP_NAME = app_test_and_measurement

# The flags passed to xcc when building the application
# You can also set the following to override flags for a particular language:
#
#    XCC_XC_FLAGS, XCC_C_FLAGS, XCC_ASM_FLAGS, XCC_CPP_FLAGS
#
# If the variable XCC_MAP_FLAGS is set it overrides the flags passed to
# xcc for the final link (mapping) stage.

# These flags define two build configurations - one for U-series and one for
# the xCORE-200 series.
XCC_FLAGS_X200 = -Wall -g -report -DXUD_SERIES_SUPPORT=XUD_X200_SERIES

VERBOSE = 1

# The USED_MODULES variable lists other module used by the application.
USED_MODULES = lib_gpio lib_logging lib_usb lib_xassert

#=============================================================================
# The following part of the Makefile includes the common build infrastructure
# for compiling XMOS applications. You should not need to edit below here.

XMOS_MAKE_PATH ?= ../..
include $(XMOS_MAKE_PATH)/xcommon/module_xcommon/build/Makefile.common
Does anyone have any insight as to why I cannot break on any C module? Also, can anyone confirm that they have been successful in resolving a breakpoint in a C file while debugging in xTIMEcomposer?

Thanks!!


View Solution
srinie
XCore Addict
Posts: 158
Joined: Thu Mar 20, 2014 8:04 am

Post by srinie »

Hi,
Couple of things to try?

* set the lowest optimization level for the specific file
XCC_FLAGS_<file_name>.c = $(XCC_FLAGS) -O0 -g

* does the symbol where debug point is placed is indeed available in the obj dump?
- able to access the symbol memory address?
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

Thanks for the suggestions.

I've tried adding your line to my makefile. In this case I was targeting parser.c so my addition was:

Code: Select all

XCC_FLAGS_parser.c = $(XCC_FLAGS) -O0 -g
However, I observed the same behavior as before where breakpoints anywhere in parser.c can be resolved.

With or without that extra line, while debugging, I can pause execution and view any function in any C file in the disassembly window. I can also view any variable within scope in the memory monitor.

What is interesting is that I can actually pause execution, lookup the function in a C file in the disassembly window and place a breakpoint on it. The breakpoint will get hit. When it does get hit, the IDE is able to properly resolve the breakpoint in disassembly to the relevant line in the C source code file. However, at that time, if I try to place a breakpoint on a line in the C file - even where the debugger had already resolved the function address to the relevant line in the C source code file - I still get the unresolved breakpoint warning.

All of this tells me that debugging info for the C files are getting generated but the IDE is having a hard time mapping source code lines to disassembly. My next experiment is going to be to create a new project with a simple xc file where main.xc calls a simple function in a C file and see if I can set breakpoints there.

In the meantime, can anyone chime in on whether or not they have been able to debug C files in xTIMEcomposer 14? My version info below:

Code: Select all

Version: Community_14.1.0 (build 17291, Jul-23-2015) 
Copyright 2015 Xmos Ltd.

Thanks!!
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

I created a small project to test this problem. Here is the code.

Code: Select all

/*
 * C Debug Test.xc
 *
 *  Created on: Feb 19, 2016
 *      Author: Amandio
 */


#include "math.h"

int main(){

    int x = 3;
    int y = 5;

    int ans1 = add(x, y);
    int ans2 = sub(x, y);

    while(1);

    return 0;

}

Code: Select all

/*
 * math.h
 *
 *  Created on: Feb 19, 2016
 *      Author: Amandio
 */

#ifndef MATH_H_
#define MATH_H_

int add( int x, int y );

int sub( int x, int y );

#endif /* MATH_H_ */

Code: Select all

/*
 * math.c
 *
 *  Created on: Feb 19, 2016
 *      Author: Amandio
 */

int add( int x, int y){

    return x + y;
}

int sub ( int x, int y ){

    return x - y;
}
So, pretty basic. I used the same flags in the Makefile for the Debug config to produce debugging info and turn off optimization:

Code: Select all

XCC_FLAGS_Debug = -O0 -g
When I run this program in the debugger, I observe the same problem. I can set breakpoints to my heart's content in the xc file, but when I double-click to the left of the line number (or right-click and click "Toggle Breakpoint" or click "Add Breakpoint..." in the context menu) the breakpoint symbol appears but is unresolved when I debug the program. Therefore the breakpoints won't get hit. The workarounds I found before still work where I can suspend the running program and add a breakpoint in the Disassembly view of a c file. I can also resolve a breakpoint to the caller of the c function in an xc file and step into the c file just fine.

A new workaround I just discovered is that I can click on the down arrow in the menu bar of the breakpoints window and add a function breakpoint where the breakpoint will be resolved to the function. This is far more helpful but still limiting.

So it looks like xTIMEcomposer had an issue with resolved breakpoints by line number in C files because I can resolve them by other means.

After perusing the XMOS website looking for any solution, I noticed on the main download page for xTIMEcomposer that the latest release is 14.1.2 and I was running 14.1.0. Even though the release notes didn't mention anything fixed along the lines of what I experienced I decided to uninstall 14.1.0 and install 14.1.2 and now the problem is resolved!!!

I can finally set and resolve breakpoints in my c files!
hessa59
Active Member
Posts: 37
Joined: Sat Mar 18, 2017 7:19 pm

Post by hessa59 »

I am running 14.24 with a startkit on windows 8.1 and experiencing similar problems

a) can set a break point
b) but program won't stop there (unresolved breakpoint)
c) if program is paused I can single step

I did notice this error when applying the debug configuration
".gbdinit: no such file or directory"
but don't know what it means.

I think your add function breakpoint is going to come in very handy!
I looked in the archived xtime composer location and couldn't find 14.1.2 so thanks for posting your workarounds :)
Post Reply