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

[Tony Hosking]

These behaviors are derivative of the GNU tools, not CM3 per se.  The  
munged names are understood by m3gdb, which uses them to obtain type  
information.  You don't see the munged name in m3gdb.

On Feb 13, 2008, at 5:18 AM, Jay wrote:

>  >> 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". Check it out.