stacktrace doesn't honor --excessivestacktrace

[timotheecour]

as shown in #9, see note 4
I'm expecting full paths to be shown, just as in nim's stacktrace:on, when specifying --excessivestacktrace; in particular this is useful if some files our out of cwd, but not just that: in some cases programms can change the cwd and the generate a stacktrace, so absolute paths make this clear.

Happy to provide more details here in case this isn't clear enough.

[stefantalpalaru]

I don't think it's relevant for this library. We're just using the paths we get from libbacktrace which gets them from the debugging info which comes from Nim-generated #line ... pragmas.

See:

nim-libbacktrace/libbacktrace_wrapper.c

Line 219 in f0bbe7e

cb_data->di_data[cb_data->next_index].filename = xstrdup(filename);

Then go back to the test case where you see relative paths and look at the Nim-generated C files. If they match, it's not our problem.

[timotheecour]

i'm happy to look into fixing this in nim repo but let's please keep this bug open in the meantime, for end users this is an implementation detail: it should work

[stefantalpalaru]

Sure.

[timotheecour]

@stefantalpalaru after investigating this here's my observations:

• --listfullpaths:on|off has no effect
• --excessivestacktrace:on|off has no effect
• whether a module will show as absolute or relative depends on whether it is rooted strictly under PWD:

nim c -d:nimStackTraceOverride --import:libbacktrace --debugger:native --listfullpaths:on --excessivestacktrace:on -o:/tmp/z02 -f --skipparentcfg --skipusercfg /pathto/main.nim

if we are compiling under:
/foo/bar
and the module is under
/foo/fun.nim => will show absolute path /foo/bar/fun.nim
/foo/bar/fun.nim => will show absolute path /foo/bar/fun.nim
/foo/bar/baz/fun.nim => will show relative path baz/fun.nim

the latter case is a bug; at least there should be a way to customize this; in many cases this is surprising behavior and complicates things (eg some script may change dir before compiling, and the generated relative paths would not be meaningful anymore)

note that these all show the correct absolute paths:

• the #line directives generated by nim
• dwarfdump /tmp/z02.dSYM
• lldb

so the problem lies either in this library or its dependencies; it looks like somewhere it tries to take relative paths wrt PWD.

note

an ugly workaround could be to make cgen insert a space in the line directives, eg:

  #line 37 "/pathto/fun.nim"
=>
  #line 37 " /pathto/fun.nim"

but it may break other things.

[timotheecour]

super hacky and fragile workaround: use --passc:-ffile-prefix-map=$(pwd)=$(pwd)//

nim c -d:case1 -d:nimStackTraceOverride --import:libbacktrace --debugger:native --listfullpaths:on --excessivestacktrace:on -o:/tmp/z02 -f --skipparentcfg --skipusercfg --hint:cc --listcmd --passc:-ffile-prefix-map=$(pwd)=$(pwd)// $timn_D/tests/nim/all/t12148.nim

refs https://reproducible-builds.org/docs/build-path/

[timotheecour]

maybe the problem is upstream, see ianlancetaylor/libbacktrace#72 i just filed; looks like DW_AT_comp_dir is incorrectly used