Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000700Taste[All Projects] Ocarina - C code generationpublic2017-10-26 14:242021-05-21 09:52
Reportermiguel_munoz 
Assigned Tomaxime 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformAllOSOS Version
Summary0000700:

Duplication of source files makes it difficult to use a graphical debugger

Description

The build process creates many .c and .h files in binary.c that have identical names but different content.

For instance, if we have a function f1, the original code is located at:

f1/f1.h
f1/f1.c

In binary.c we find:

binary.c/f1/f1.h
binary.c/f1/f1.c
binary.c/f1/f1/f1.h
binary.c/f1/f1/f1.c

Of these, the two copies of f1.h are identical. For f1.c, the first one contains the empty skeleton (as generated by taste-generate-skeletons), and the second one contains the actual implementation (copy of the original f1/f1.c).

When trying to debug with a graphical debugger, it is often difficult and error prone to have this duplication. In addition, not all the files are compiled into the final binary.

As a result, debugging TASTE applications is very difficult for new users. It would be desirable to avoid the generation of any files that are not needed for the compilation, in order to avoid clutter. Furthermore, to ease the debug workflow, it would be preferable to use the original .c and .h files in the build, rather than a copy of them (maybe a symbolic link could be used?).

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0003062)
hugues (administrator)
2017-10-26 14:38

Thanks for the feedback. The files you see are not related to Ocarina itself, but to the orchestrator that creates a workspace for code generation and compilation

I'm reassigning to Maxime to have his view on this issues.

(0003064)
ttsiodras (administrator)
2017-10-26 14:57

Removing the skeleton .c files and thus leaving only one copy of whateverFunction.c under f1/ would be easy.

But first, let me see if I missed something: when you launch the binary under the debugger, the binary knows what sources it came from (at least if you built with --debug, which is by default inside the build-script.sh). When e.g. you place a breakpoint in function "foo", GDB will stop there and show you the listing from the file hosting "foo" - you don't need to know whether "foo" is in f1/f1.c or binary.c/fi/f1.c or whatever else, GDB will show it (and with the TUI enabled - e.g. via C-x C-a) you will actually be able to navigate inside the source code.

That is, I am missing the "I need to have a single file.c during debugging with GDB". IMHO you shouldn't need to know in the 1st place - you should work in terms of functions and symbols, not files and lines - these show up from GDB automatically.

(0003065)
miguel_munoz (developer)
2017-10-26 15:44
edited on: 2017-10-26 15:49

That is true in general. However, when working in a cross-development environment, you can easily find more complex cases.

The specific case where we're having problems with this is using Eclipse. To debug with Eclipse you need to create a project in your workspace. We're debugging a TASTE model that is built from its own C source files, together with the sources contained in tool-inst/po-hi-c, and a few other user libraries. In order to create a debug project, we need to create symlinks from the Eclipse workspace to each of the folders. The file paths then don't match those contained in the executable. Eclipse then falls back to file names (without path), and when there are two candidate paths with the same name it asks you to select one manually.

Another similar scenario that we've found in the past is that, as we have a DMON license for Windows only, we have to build the software in the TASTE VM and then debug it from Windows using the GR tools. The file paths then don't match, and must be manually adjusted (you can tell GDB to replace paths).

Even when looking into the generated source code using grep, the duplication of files can be very confusing.

While it's clear that these complications have more to do with the debug setup than with TASTE, it would anyway be nice to reduce as much as possible file clutter in the TASTE side to facilitate the work of the developer.

(0003067)
ttsiodras (administrator)
2017-10-27 09:20
edited on: 2017-10-27 09:21

The specific case where we're having problems with this is using Eclipse.
To debug with Eclipse you need to create a project in your workspace.
We're debugging a TASTE model that is built from its own C source files,
together with the sources contained in tool-inst/po-hi-c, and a few other
user libraries. In order to create a debug project, we need to create
symlinks from the Eclipse workspace to each of the folders.

Don't take this the wrong way - but in my humble opinion, launching good old GDB (or DDD, if you prefer a graphical debugger) sounds like a LOT less work that all of the above. And especially after moving to the Leon targets, adding this kind of complexity on top... well...

Just saying; you should perhaps consider keeping it simple - and avoid having so many layers on top that can go wrong (what if the symlink points to the wrong file because the same filename exists in different SARGON drivers, for example?)

Anyway, I added your request to the TODO - it basically requires an option in Maxime's buildsupport (e.g. --no-skeleton-body) that the orchestrator can use to avoid generating the duplicate files. But fair warning: this will indeed be of low implementation priority... our recommendation still stands, to use good old GDB - in the case of the SARGON work for example, over GRMON's gdbserver protocols.

Speaking as an old grey embedded engineer, you will avoid a LOT of headaches if you keep things as simple as possible ;-)

(0003068)
miguel_munoz (developer)
2017-10-27 11:29

There is a famous quote from Einstein about simplification. Finding the right spot of simplification is the key!

Please, understand this feedback from the point of view of users who have a first contact with TASTE (this comes from the experience of having new people working in SARGON and ESROCOS). When you work with a new codebase, an IDE that understands the semantics of the code, not only the syntax, is invaluable. This is why we recommend that TASTE plays as nice as possible with these tools, even if we understand that this is a long term goal.

(0003069)
ttsiodras (administrator)
2017-10-27 11:57

I'd argue then that Einstein's "but not simpler" doesn't stop at Eclipse - it stops at GDB ;-)

But seriously, like I said - we'll try to fit this in as well; just after we deal with the high-priority things. We do care about improving the user experience of TASTE - and we appreciate your feedback Miguel. Keep it coming!

(0003774)
maxime (administrator)
2021-05-21 09:52

This is fixed with Kazoo - files are not duplicated any longer during the build


- Issue History
Date Modified Username Field Change
2017-10-26 14:24 miguel_munoz New Issue
2017-10-26 14:24 miguel_munoz Status

new => assigned

2017-10-26 14:24 miguel_munoz Assigned To

=> user2

2017-10-26 14:38 hugues Note Added: 0003062
2017-10-26 14:38 hugues Assigned To

user2 => maxime

2017-10-26 14:57 ttsiodras Note Added: 0003064
2017-10-26 14:57 ttsiodras Assigned To

maxime => ttsiodras

2017-10-26 15:44 miguel_munoz Note Added: 0003065
2017-10-26 15:49 miguel_munoz Note Edited: 0003065 View Revisions
2017-10-27 09:20 ttsiodras Note Added: 0003067
2017-10-27 09:20 ttsiodras Assigned To

ttsiodras => maxime

2017-10-27 09:21 ttsiodras Note Edited: 0003067 View Revisions
2017-10-27 11:29 miguel_munoz Note Added: 0003068
2017-10-27 11:57 ttsiodras Note Added: 0003069
2021-05-21 09:52 maxime Note Added: 0003774
2021-05-21 09:52 maxime Status

assigned => closed

2021-05-21 09:52 maxime Resolution

open => fixed



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker