embitzForum
  • Status Waiting on Customer
  • Percent Complete
    0%
  • Ticket Type Bug Report
  • Category
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Normal
  • Reported Version 2.30
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: EmBitz IDE
Opened by crazyfellow (CrazyFellow) - 2015-01-17
Last edited by (EmBitz) - 2016-12-08

Ticket#213 - GDB does not always find source files (custom makefile projects; location of .ebp file)

Under certain circumstances gdb does not find the correct source file when setting a breakpoint.
gdb says: “Error: No source file named ../../../../projects/p1/src/main.c.”

The problem occurs with custom makefile projects and depends on the location of the project file.


To demonstrate this, I build a small environment similar to what I'm using, but without the cmake/ninja toolchain in order to keep it simple.
A batch file handles the external build commands so it should nearly run out of the box.
For more details, see the readme in the attached zip file.

This ticket does not depend on any other tickets.

zainka (zainka)
Friday, 20 February 2015, 07:58 GMT
This may somewath relate to forum post: http://www.emblocks.org/forum/viewtopic.php?f=19&t=448
(EmBitz)
Thursday, 08 December 2016, 10:28 GMT
Hi,

First sorry for this very long delay.

Nevertheless, I tried this morning with EmBitz to reproduce this and it is working fine here. I can place breakpoints in debug-p1 in the main file.
Is this solved for you in EmBitz??
crazyfellow (CrazyFellow)
Thursday, 08 December 2016, 20:58 GMT
Hi,

which project file did you used / was the active one of the Workspace?
There is one in bp_test\output\debug (ALL) and another one in \bp_test\output\debug\projects\p1 (P1).

All: bp_test\output\debug has a p1 and a p2 target / directory. Debug-P1 of this project is the one, where you can set breakpoints.
P1: bp_test\output\debug\projects\p1 includes only the Debug-P1 target. This is the ohne where you can't set a breakpoint.

I tried it with EmBitz 1.11, but there is still the "Error: No source file named ../../../../projects/p1/src/main.c." problem in the P1 Project.



------------------------------
Changes in build.bat:
- Path changed to ...\EmBitz\1.11
- Added -mthumb to compiler and linker parameters because of "error: target CPU does not support ARM mode"
(EmBitz)
Saturday, 10 December 2016, 06:16 GMT
Hi,

I already made those changes and I have a buildable project.

- I can put breakpoints in P1.
- I can't debug Debug-All because the debugger option is grayed out. (no single target in focus)

Am I missing something?
crazyfellow (CrazyFellow)
Sunday, 11 December 2016, 20:40 GMT
Hi

> I already made those changes and I have a buildable project.
My comment was only to make sure / to ask if you didn't change any other unexpected flags or settings.

Debug-All:
This is not intended to be a executable / debugable target.
In the real toolchain this All-Target is to build the binarys for all devices.
I only added this (as well as P2) to show the idea behind that directory, project and target structure.

The "All" in my previous post was the project name / title shown in EmBitz for bp_test\output\debug\debug.ebp

But still the question ist, what is the reason for the different behavior if you try to reproduce it.

I made some screen shots to show the behavior of the to project files when I try to set a breakpoint.
- Projectfile-P1_ebp.png an Projectfile-debug_ebp.png
are the two projects opened in one workspace. The two relevant targets are commented with "A1" and "B1".
This labels will be used subsequent.
- Projectfile-P1_ebp-Breakpoint.png and Projectfile-debug_ebp-Breakpoint.png
show the behavior of "A1" and "B1":
- The session is running while I
- try to set a breakpoint on h++ in line 9
- In both logs you can see that the debugger stops the execution at main.c:9 (above the blue line)
- but then "A1" can set the breakpoint successfully while "B1" fails.
In "A1" the shown path to main.c are the same (while the cpu is stopped and after the breakpoint message).
While in "B1" the error message shows a different path (additional "../../" and "/" instead of "\")

Is it possible to capture the inter process communication of EmBitz an the GDB to see the commands send to GDB and not only the response?
Maybe this could help to see if there is something different on our PCs.

Loading...