raddbg should warn when a source file is newer than executable

[JuanDiegoMontoya]

Currently, raddbg does not warn when the source file (e.g., one with a breakpoint in it) is newer than the executable. This can cause confusion when breakpoints do not match with the source code. Visual Studio, gdb, and lldb warn or otherwise indicate when this situation occurs, and raddbg should too.

[nukoseer]

Is there any relation between targets and source files? Idk some kind of a project structure like these 3 source files and this target makes one project etc.. I tried to implement this behavior but when there are multiple targets and source files from different projects I could not figure out how to separate/distunguish them.

[ryanfleury]

Is there any relation between targets and source files?

No, there is no such relationship; a target is only a debugger entity which primarily encodes a combination of: (a) an executable path, (b) arguments for that executable, (c) working directory, and (d) an optional entry point string (as well as other entity data, like color and label).

One source file can not necessarily be deemed up-to-date or out-of-date in a vacuum; it can only be considered as such when also considered with a debug info file (e.g. by either comparing the timestamp, or by comparing a hash or checksum of the text file as it currently is with that stored in debug info, etc.).

But one source file doesn't necessarily map to one debug info file; the same source file can be (and often is) used in multiple modules, and there may be line info in that source file for either module. Therefore, it may be simultaneously up-to-date and out-of-date, and so the job of the debugger is to basically identify all of the relevant debug info files for a given source file (this is done with e.g. line info visualization), and find all issues, and then just visualize that.

Currently we don't have anything in the format for checksums/hashes of source files, which would be the preferable solution in my opinion (if you just use timestamps, then e.g. accidentally adding a line, then removing a line, would still show as "out of date", even though it's identical to what the compiler saw), so the proper solution for this goes a bit deeper than what the infrastructure directly supports.

[forrestsmithfb]

@ryanfleury, how would you feel about .raddbg files containing (optionally encrypted?) source code?

SymbolServer + SourceIndexing is genuinely magical. Being able to attach a debugger and automagically get both symbols and source code is just 👨‍🍳🤏💋

Almost no one does source indexing because it's a super pain in the ass. There's an opportunity here to take things to the next level and make this the new standard.

[ryanfleury]

@forrestsmithfb Yeah, in my opinion, debug info should just contain a copy of all source code which was used in the build of whatever module the debug info is for (with the option to strip it out). That would eliminate this issue entirely, and it would be very simple to add to the RADDBG debug info format. But it makes more sense once we are not converting the RADDBG files from PDBs (where we don't know if the paths in the PDB refer to valid source files on disk), and it makes more sense if/when compilers/linkers actually generate RADDBG files directly.

[forrestsmithfb]

I'm delighted you agree. I wasn't sure if that idea would be considered a good one or not.

it makes more sense if/when compilers/linkers actually generate RADDBG files directly.

I love the ambition. Glorious!

That said, I expect/hope RAD Debugger to be super useful far before toolchains generate RADDBG files natively.

Resolving file paths to embed can be moderately obnoxious and non-trivial when using distributed build systems and caches. I expect it would be easy to support a command to query RADDBG files for a list of relevant files paths and a command to provide those files. This feels like a pretty low-cost / high-value feature prior to native generation. I already have to run a post-process to both inject source indexing and upload symbols.

[ryanfleury]

As of b5e604e, I've added some visualizations to the source view to show when a file's timestamp is newer than an executable which was produced by a build which used the file.

In the future, I'll be adding support to the RADDBG format for file checksums (and later on, the source code text itself) which will improve this feature. That's all on my list when I get to doing another pass over the format, so I'll be closing this issue now.