compile time function to generate line number information for debugging

[hasenj]

To help with debugging, it would be very useful to have a function that reports line information.

For example, have a function@lineinfo() which could return something like a struct { filename: []const u8, line: u64 } or something like that.

[PavelVozenilek]

File/line information should be also part of test metadata available for the test runner, as suggested in #567.

[PavelVozenilek]

For the C allocator I designed every alloc/free function automatically and invisibly passes down __FILE__ / __LINE__ information, from where it was invoked. This information is kept in the header of every allocated block. Its use requires no extra typing and it exists only in debug mode.

In similar way, when I create some important object (say an associative array), it has field with file/line where it was constructed.

It turned out not to be especially useful (VC++ debugger is enough for my needs) and serves mostly as assurance that if things go really bad there will be at least something to get a clue. [I also experimented to store full stack trace instead of single file/line. It is relatively easy (with the help of Win32), but eventually I decided it has too low value for its performance impact.]

---

If Zig acquires such feature it should be:

1. non-intrusive. One should not be forced to type @lineinfo noise everywhere.
2. no-op in release mode, with possible option to enable it explicitly when release version has a problem.

As an idea for (1): if inside a function there's assignement =@lineinfo, then the function should get hidden parameter (equivalent of __FILE__ / __LINE__) automatically filled at its call place.

[PavelVozenilek]

Support for other debugging metadata may be also considered. Apart of file/line and stack trace there could be:

• timestamp, when a thing is created
• thread ID and/or process ID, where the thing is created
• human readable unique name or description (some games use this trick to help with debugging)
• etc

Support could mean keeping syntactic noise low when the feature is used. In C it gets ugly very fast:

#ifdef DEBUG
  time_t timestamp;
#endif

  ...

#ifdef DEBUG
  timestamp = now();
#endif  

 ...

#ifdef DEBUG
  ...

[andrewrk]

There is a better way to do this, which is with @returnAddress. Put it in a function like this:

noinline fn lineInfo() usize {
    return @returnAddress();
}

This depends on #640.

This gives you a usize which is the address of the machine code that called lineInfo. Next, one can use std.debug to find out what source file, line, column, and compilation unit the address is in. This depends on having debug info available. Or one can save these addresses in any format and then transfer the information to another machine which has the debug symbols for analysis.

This is the Zig way to do this. Although @lineInfo would be convenient and work by putting the information directly in the binary, I see this as the 95% solution. Instead I want to encourage users to aim for the 100% solution by doing what I described. If we all standarize on using machine code addresses + debug info, everyone benefits.

[daurnimator]

@andrewrk if that's the case, then there should be a way to look up debug information for the running binary (which may obviously be unavailable).

[andrewrk]

@daurnimator there is- that's how stack traces work in Zig. If one chooses to make debug info unavailable (or available but on a different server, etc), they have decided that they want a leaner binary without the debug info. And so not having @lineInfo respects that decision. Note that you can look up addresses in debug info offline. That's how gdb core dumps work. I'm confident that all the use cases have reasonable solutions here.

[daurnimator]

there is

What is the function(s) in the std library for it?

I'm confident that all the use cases have reasonable solutions here.

Yeah it makes sense to me.

[andrewrk]

look around here:

zig/std/debug/index.zig

Line 174 in c58b802

try printSourceAtAddress(debug_info, out_stream, return_address, tty_color);

[daurnimator]

So really, this issue can be solved with:

fn getLineNumber() !usize {
    const address = @returnAddress();
    const di = try getSelfDebugInfo();
    const cu = try findCompileUnit(di, address);
    // TODO: dispatch to correct getLinuxNumberInfo
    return try getLineNumberInfoDwarf(di, cu.*, address);
}

fn main() !void {
   const currentline = (try getLineNumber()).line;
}

I think this issue could be reopened as a feature request to add a similar function to the standard library.

[andrewrk]

This has been re-opened for consideration in #2029

[KeithBrown39423]

Update?

[nektro]

this was added as https://ziglang.org/documentation/master/#src
also in the future please consult one of our great Communitys for questions :)