After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734953 - The #line directive to c file doesn't include the path
The #line directive to c file doesn't include the path
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Code Generator
0.24.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks: 688447
 
 
Reported: 2014-08-17 16:07 UTC by Carl
Modified: 2018-05-22 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
don't write line directives when not needed (1.49 KB, patch)
2014-08-25 12:49 UTC, Luca Bruno
none Details | Review
Screenshot of code changes for file paths (340.07 KB, image/jpeg)
2018-03-16 15:08 UTC, Jørn Christensen
  Details

Description Carl 2014-08-17 16:07:39 UTC
When vala generates the c file, the #line directive mentioning c files (likely at the end of methods/functions) doesn't include the path to the c file.

This is annoying as it breaks the debugging flow and makes addr2line report wrong file path.
Comment 1 Luca Bruno 2014-08-25 12:49:08 UTC
Created attachment 284399 [details] [review]
don't write line directives when not needed

Does this fix your issues?
Comment 2 Carl 2014-09-24 10:55:04 UTC
I did the following: 

git clone https://github.com/GNOME/vala.git
cd vala
<applied the patch>
sudo apt-get install flex
sudo apt-get install bison
./autogen.sh
./configure 
sudo make install

And make clean && make on my application

And it didn't change anything.
Comment 3 Luca Bruno 2014-09-24 10:58:20 UTC
But you shouldn't see the #line without the path anymore, right?
Comment 4 Carl 2014-09-24 11:21:12 UTC
As a sidenote, the correct sequence to build vala is 

git clone https://github.com/GNOME/vala.git
cd vala
sudo apt-get install valac
sudo apt-get install flex
sudo apt-get install bison
./autogen.sh
./configure 
sudo make install
sudo ldconfig
Comment 5 Carl 2014-09-24 11:45:39 UTC
Here a sample of C file generated http://pastie.org/9590367

There is still a directive 

line #line 91 "error_colors.c"
Comment 6 Luca Bruno 2014-09-24 11:51:41 UTC
Can you please paste the Vala file?
Comment 7 Carl 2014-09-24 11:53:56 UTC
http://pastie.org/9590441

valac --version
Vala 0.26.0.11-a47f-dirty
Comment 8 Luca Bruno 2014-09-24 11:56:28 UTC
Repasting here to avoid pastebin expire:

private void this_will_crash ()
{
	var hi = "johnny !" ;
	assert (hi == "wiseau");
    message ("I haven't crashed") ;
}

int main (string[] args) {
	// Soothing, uh?
	Stacktrace.default_highlight_color = Stacktrace.Color.GREEN ;
	Stacktrace.default_error_background = Stacktrace.Color.WHITE ;
    Stacktrace.register_handlers () ;

	stdout.printf("  This program will crash with fancy colors!\n" ) ;

    this_will_crash () ;
    return 0 ;
}
Comment 9 Carl 2014-09-24 11:57:29 UTC
Complete file and project here :
https://github.com/PerfectCarl/vala-stacktrace/blob/master/samples/error_colors.vala
Comment 10 Jørn Christensen 2018-03-16 09:11:33 UTC
This is still an issue!

I just (like... spend half a day on this) installed Visual Studio Code and was happy that I could debug (step through) Vala code with VSC. Then I became a bit disappointed that VSC would report that it could not find c-files. I debugged the issue and came to the same conclusion... The Vala compiler emits full paths for #line-statements for .vala files, but only filename (or relative paths?) for .c-files.

I was about to file a bug, when I decided to search a bit.... and yes... a 3 year old bug report! It seems to me to be such a simple fix (if you know your way around the codebase) and still it has not gotten any attention.

Valac version: 0.36.6
Comment 11 Al Thomas 2018-03-16 13:40:58 UTC
(In reply to Jørn Christensen from comment #10)
> I just (like... spend half a day on this) installed Visual Studio Code and
> was happy that I could debug (step through) Vala code with VSC.

That sounds good. How easy was it to get that working? I assume the half day includes investigating the #line problem? A blog post or some details on how you set this up would be helpful to add to our wiki about tools.

> Then I became a bit disappointed that VSC would report that it could not find
> c-files. I debugged the issue and came to the same conclusion... The Vala
> compiler emits full paths for #line-statements for .vala files, but only
> filename (or relative paths?) for .c-files.

It's the filename only. I've just done a test build with Meson. Meson now uses the --basedir switch with valac and only the filename is output. See https://github.com/mesonbuild/meson/pull/2413 for details on that change to Meson. A Meson developer did ask at the time for the C filenames to be flat instead of output to directories.

The filenames should be relative in order to generate reproducible builds (https://reproducible-builds.org/). This is already in our bug tracking - see https://bugzilla.gnome.org/show_bug.cgi?id=769935 How do relative paths work with tools like VSC? Although I note MSVC has the /FC switch (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full paths in diagnostics.

At the moment my understanding is the #line to the C file is printed at the end of the C function. What use case do have for this? At the moment it looks like people have tried to use this for breakpoints in gdb (https://bugzilla.gnome.org/show_bug.cgi?id=664922) and symbol translation for stack traces (https://bugzilla.gnome.org/show_bug.cgi?id=738784).

In terms of writing tests for the Vala compiler test suite. We could use assert with __LINE__ and __FILE__ to check the values are as expected. At present we don't have bindings for __LINE__ or __FILE__. Something like this works:

void main () {
    print ("%d\n",Debug.LINE_NUMBER);
    print (Debug.FILE + "\n");
}

namespace Debug {
    [CCode (cname = "__LINE__")]
    extern const int LINE_NUMBER;

    [CCode (cname = "__FILE__")]
    extern const string FILE;
}

> I was about to file a bug, when I decided to search a bit.... and yes... a 3
> year old bug report! It seems to me to be such a simple fix (if you know
> your way around the codebase) and still it has not gotten any attention.

Vala is currently maintained by a small team, who only have so much time to work on it. The number of open bugs has gone down significantly over the past year or two thanks to the efforts of one or two core people. Getting additional contributors on board is a goal for us. So if you have any insights about how this could work better that would be helpful. Including the use of the #line C pre-processor directive in Vala's generated C.
Comment 12 Jørn Christensen 2018-03-16 15:07:21 UTC
(In reply to Al Thomas from comment #11)
> (In reply to Jørn Christensen from comment #10)
> > I just (like... spend half a day on this) installed Visual Studio Code and
> > was happy that I could debug (step through) Vala code with VSC.
> 
> That sounds good. How easy was it to get that working? I assume the half day

The initial set was actually very straight forward and worked out of the box.

1) I installed Visual Studio Code
2) I build the project (Shotwell in this case) outside MSC with debug option.
3) MSC saw that I opened vala files and suggested me to install the Vala Code plugin.
4) Pressing F5 (Debug) MSC guided me how to configure a debug session
5) Stepping through Vala code just worked, but I got errors about not-found C-files.

I think I saw somewhere that MSC was listed as having a bit of Vala compatibility, so I am not sure how much of a guide is needed.

I *think* that the modules responsible for being able to debug Vala is actually not the Vala Code plugin (I think it only does the syntax highlighting) but the pre-installed C/C++ plugin. I *think* it is actually just the interaction with GDB that works any file marked as source file.

> > Then I became a bit disappointed that VSC would report that it could not find
> > c-files. I debugged the issue and came to the same conclusion... The Vala
> > compiler emits full paths for #line-statements for .vala files, but only
> > filename (or relative paths?) for .c-files.
> 
> It's the filename only. I've just done a test build with Meson. Meson now
> uses the --basedir switch with valac and only the filename is output. See
> https://github.com/mesonbuild/meson/pull/2413 for details on that change to
> Meson. A Meson developer did ask at the time for the C filenames to be flat
> instead of output to directories.
> 
> The filenames should be relative in order to generate reproducible builds
> (https://reproducible-builds.org/). This is already in our bug tracking -
> see https://bugzilla.gnome.org/show_bug.cgi?id=769935 How do relative paths
> work with tools like VSC? Although I note MSVC has the /FC switch

Relative to what?

I tried making all the paths relative to the build dir (*) and it worked fine with VSC – but why it works, I don't know. According to the launch configuration, the CWD should not be the build dir, but the project dir (i.e. the parent dir of build/). So there is some link here I am missing.

(*) Is this standard for meson / ninja? To have a dir names build/ and all generated output there? I am still very new to Meson / Ninja, which also was part of my half day trying to understand whether the bug was theirs, and when not, if it was possible to add a (scripting) step between Valac and CC. In the end, I wrote a valac wrapper and put it first in path!


> (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full
> paths in diagnostics.

This is for Microsoft Visual Studio (i.e. the full edition with compiler and all). I am working with the free open source Visual Studio Code. No compiler included here. 

But perhaps your point with that link was another one...?

> At the moment my understanding is the #line to the C file is printed at the
> end of the C function. What use case do have for this? At the moment it

It is much more comprehensive than that. It is for each code line in the c-file. If the line matches a vala code line, then that is added as a comment. If it is auto generated code / hidden code, then the C-line is added.

See my attachment for a screenshot of a code file. You can see how vala references are absolute, while c-references are filename only. And you can see my scripting changes to the file.

I am not sure why the c-lines are needed. I mean... normal C-programs do not have these #line comments and they are debugable just fine. Perhaps it is because Vala code lines are marked and thus it confuses the debugger (-parser) if C-lines are not marked?

> looks like people have tried to use this for breakpoints in gdb
> (https://bugzilla.gnome.org/show_bug.cgi?id=664922) and symbol translation
> for stack traces (https://bugzilla.gnome.org/show_bug.cgi?id=738784).

I think that is how GDB / VSC uses those as well.

> > I was about to file a bug, when I decided to search a bit.... and yes... a 3
> > year old bug report! It seems to me to be such a simple fix (if you know
> > your way around the codebase) and still it has not gotten any attention.
> 
> Vala is currently maintained by a small team, who only have so much time to
> work on it. The number of open bugs has gone down significantly over the

Fair enough.

Sorry for my outcry. I was just feeling a bit frustrated. I have been pondering the last couple of days whether I should dive into Shotwell (but was frustrated with the lack of good IDEs for Valac), dive into Darktable (which I like for the photo editing but not for the photo management) or try to start something new (in Qt / C++ which seems to have good tool support).

> past year or two thanks to the efforts of one or two core people. Getting
> additional contributors on board is a goal for us. So if you have any
> insights about how this could work better that would be helpful. Including
> the use of the #line C pre-processor directive in Vala's generated C.

I do not have a lot of insights. I just hacked a bit on my computer.

~Jørn
Comment 13 Jørn Christensen 2018-03-16 15:08:01 UTC
Created attachment 369786 [details]
Screenshot of code changes for file paths
Comment 14 Al Thomas 2018-03-16 16:45:29 UTC
Hi Jørn,

Thanks for your comments, they are helpful.

(In reply to Jørn Christensen from comment #12)
> I *think* that the modules responsible for being able to debug Vala is
> actually not the Vala Code plugin (I think it only does the syntax
> highlighting) but the pre-installed C/C++ plugin. I *think* it is actually
> just the interaction with GDB that works any file marked as source file.

Sounds reasonable. I read that C/C++ plugin also supports LLDB and Visual Studio Windows Debugger (https://code.visualstudio.com/docs/languages/cpp#_debugging). From the Vala perspective we want to find if there is a de facto standard for filenames. 


> Relative to what?

I'm not sure yet. I was thinking relative to the project root directory. So all Vala files are in that directory or below. This would meet the reproducible build requirement.


> I tried making all the paths relative to the build dir (*) and it worked
> fine with VSC – but why it works, I don't know. According to the launch
> configuration, the CWD should not be the build dir, but the project dir
> (i.e. the parent dir of build/). So there is some link here I am missing.
> 
> (*) Is this standard for meson / ninja? To have a dir names build/ and all
> generated output there?

Meson is designed for out of source tree builds. So yes it is standard. Ninja can be invoked with the -C switch to change to the build directory.

It looks like `directory` is the GDB command to set a project root directory. `show directories` prints the source paths in GDB. `directory /home/me/my_project/` would add the project root to GDB. For more: https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html

I'm not sure if there is a way for Visual Studio Code to pass that to GDB. Maybe there is something about that in https://code.visualstudio.com/docs/extensions/example-debuggers. From a Vala perspective a simple filename relative to the project root would be good. This may need an option to valac to specify the project root, but otherwise it would be down to the debugger to be informed of the source directory. Not sure about LLDB or the Windows Debugger.


> > (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full
> > paths in diagnostics.
> 
> This is for Microsoft Visual Studio (i.e. the full edition with compiler and
> all). I am working with the free open source Visual Studio Code. No compiler
> included here. 
> 
> But perhaps your point with that link was another one...?

Yeah, I meant we could add an option to valac to include full source file paths. Only if necessary in my view.


> It is much more comprehensive than that. It is for each code line in the
> c-file. If the line matches a vala code line, then that is added as a
> comment. If it is auto generated code / hidden code, then the C-line is
> added.
> 
> I am not sure why the c-lines are needed. I mean... normal C-programs do not
> have these #line comments and they are debugable just fine. Perhaps it is
> because Vala code lines are marked and thus it confuses the debugger
> (-parser) if C-lines are not marked?

Hmmm, it would make it easier if they were not needed because I think C filenames should be relative to the build directory. Then again with GDB the directory could be passed with the `directory` command.

> I do not have a lot of insights. I just hacked a bit on my computer.

Your comments have given me some useful insights. Thanks. Swapping the project path for ../ in your screenshot was useful. I'm hoping the `directory` command will be enough to no longer need the ../ as well.
Comment 15 Jørn Christensen 2018-03-17 02:03:21 UTC
Hi :-)

(In reply to Al Thomas from comment #14)
> (In reply to Jørn Christensen from comment #12)
> (https://code.visualstudio.com/docs/languages/cpp#_debugging). From the Vala
> perspective we want to find if there is a de facto standard for filenames. 

Searching a bit, I found this:
https://stackoverflow.com/questions/9607155/make-gcc-put-relative-filenames-in-debug-information

In the comments to the original question, it is indicated that gcc puts the path of the code file as it gets it. I don't know if it is standard, but it sounds like a good solution.

> It looks like `directory` is the GDB command to set a project root
> directory. `show directories` prints the source paths in GDB. `directory
> /home/me/my_project/` would add the project root to GDB. For more:
> https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html

Again, this is where my knowledge falls short. I *thought* that gdb would just spit out line information that it got from the debug section put in by gcc. Why would gdb need to know source directory? I thought it was VSC (or other graphical IDE) 's responsibility to take that information and open the correct file on the correct line number. The IDE may then need a source code search path.

But clearly, I am missing something here.

> I'm not sure if there is a way for Visual Studio Code to pass that to GDB.
> Maybe there is something about that in
> https://code.visualstudio.com/docs/extensions/example-debuggers. From a Vala

My immediate bet is that it could be added to the C/C++ debugger adapter – which is open source as well. But again... I don't see why that is needed.

> perspective a simple filename relative to the project root would be good.
> This may need an option to valac to specify the project root, but otherwise

I think, like gdb, just relative to working directory of valac in the first place. And if that is not enough, then options to valac to set project root and/or use absolute paths.

> Yeah, I meant we could add an option to valac to include full source file
> paths. Only if necessary in my view.

On one hand, I think it will be fine with the relative-to-invocation path. On the other hand, if the code impact is not big, it would not hurt to implement the other options as well.

> > I am not sure why the c-lines are needed. I mean... normal C-programs do not
> > have these #line comments and they are debugable just fine. Perhaps it is
> > because Vala code lines are marked and thus it confuses the debugger
> > (-parser) if C-lines are not marked?
> 
> Hmmm, it would make it easier if they were not needed because I think C
> filenames should be relative to the build directory. Then again with GDB the
> directory could be passed with the `directory` command.

If found the line control documentation of gcc:
https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html

This clears it up a bit. Line control is needed because valac is a source-to-source compiler and thus automatic line-enumeration of the code does not work. When #line is used, all the following statements are attributed to that line. 

It also means that if the c-line enumeration were to be omitted, then (according to the documentation) multiple c-lines would be attributed to the same vala lines. Trying this, did unfortunately not work. The stepping then suddenly jumped all over the code base and my 10 minutes investigation could not figure out why.

But... for future functionality, it would be feasible if the user could choose whether to
  a) stay in vala code
  b) stay in c-code
  c) jump back and forth (which is the current behaviour, when paths are correct).

It would be nice if the debugger / IDE could do this on the fly, but otherwise, a re-compilation (perhaps of a subset of files) could be a work-around. This would require a options to valac, though (to either omit c-enumeration or vala-enumeration).


> > I do not have a lot of insights. I just hacked a bit on my computer.
> 
> Your comments have given me some useful insights. Thanks. Swapping the

Glad they did :-)

~Jørn
Comment 16 GNOME Infrastructure Team 2018-05-22 15:16:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/469.