[M3devel] full paths to sources to slightly ease debugging self-built binaries?

[Jay]

 >> And I think we should fix it so that that the symbols have full source paths. >> I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files.
 
My experience using gdb suggests that the symbols have paths like foo.m3 and/or ../bar.i3 but never "full paths".
You can tell gdb where to look for files, it isn't that hard, and it works.
 
However I would really like the paths to be full paths and gdb to automatically show the source.
(I'd also like a mode that shows no source and only assembly, switching off and on, presumably I'll find this in the gdb docs; it's pretty stinky that in the absence of source, you have to tell it display/i $pc but oh well...)
 
Now,
1) Do people mind their full paths "leaking" out in binaries they give people?
   Make the behavior an option here?
 
2) When such binaries are moved across machines, presumably you are back roughly where you started. Ok.
And then the same "fix"? Or does the full paths defeat any sort of search in provided paths?
(It's pretty obvious where this leads if you think about the implementation -- they can look for leaf path elements in a list of directories, and they can be super aggressive and do something iterative where they try cutting off an element at a time from the start of the path and append that to each "search path", and furthermore, they can "remember" which prefixes' removal tended to work and skip right to that, however that could also lead to missing other matches, and this all rapidly explodes into many probes for files and not clearly worth it; I've never implemented a debugger but I've been a greedy/whiny user. :) )
I have not at all looked into this but I assume once I do it's not that difficult to fix.
It's probably a matter of a small number of strategically placed calls to get the full path to a file.
There will be the inevitable issues with the two or more different path syntaxes (essentially, mingwin and cygwin have different syntaxes, though you can setup symlinks easily enough to make them able to share each other's paths).
 
I don't know if it plays into any "fingerprinting", and if so, that could be a total deal breaker.
I kind of expect it does not. Not in anything people expect to read/write into pickles.
Could be that switching this causes a rebuild of everything.
Could be the full and relative paths are needed, like for cm3 -ship to work or something, or for the resulting shipped .m3exports files to work. Could be some of the builtin very well hidden stuff, the quake functions that .m3exports files use need an extra parameter, but maybe not. You know, as long as only m3cg/as get the changed paths and nothing else does...
 
 
 - Jay
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080213/d5a63ec4/attachment-0002.html>