Originally shared by Thomas Mueller (dummzeuch)
Originally shared by Thomas Mueller (dummzeuch)
One thing that irked me since forever is that Grep does not find the text in all files that are used in the project. You can either find files that are explicitly included in the current project (or project group) or files in a directory. There is no way to get all files that are linked into a project, look them up in the search path and then grep them.
I have got one idea to fix that problem:
1. Read the map file (segments is enough), collect all modules mentioned in any of the lines in
Detailed map of segments
0001:00000000 0000B47C C=CODE S=.text G=(none) M=System ACBP=A9
0001:0000B47C 00000730 C=CODE S=.text G=(none) M=SysInit ACBP=A9
0001:0000BBAC 000018D0 C=CODE S=.text G=(none) M=System.Types ACBP=A9
0001:0000D47C 000009CC C=CODE S=.text G=(none) M=System.UITypes ACBP=A9
(M=xxxx is the module name, there will be lots of duplicates.)
2. Search for them using the search path (debug search path), like in the uses manager.
3. Pass that list on to the grep engine.
That should do the trick, if a map file has been generated.
Does anybody have got a better idea? Have you maybe already written some code that parses map files which you are willing to contribute? (I think there should be something in the JCL because jcldebug can use it, but I don't want to include such a large library.)
One thing that irked me since forever is that Grep does not find the text in all files that are used in the project. You can either find files that are explicitly included in the current project (or project group) or files in a directory. There is no way to get all files that are linked into a project, look them up in the search path and then grep them.
I have got one idea to fix that problem:
1. Read the map file (segments is enough), collect all modules mentioned in any of the lines in
Detailed map of segments
0001:00000000 0000B47C C=CODE S=.text G=(none) M=System ACBP=A9
0001:0000B47C 00000730 C=CODE S=.text G=(none) M=SysInit ACBP=A9
0001:0000BBAC 000018D0 C=CODE S=.text G=(none) M=System.Types ACBP=A9
0001:0000D47C 000009CC C=CODE S=.text G=(none) M=System.UITypes ACBP=A9
(M=xxxx is the module name, there will be lots of duplicates.)
2. Search for them using the search path (debug search path), like in the uses manager.
3. Pass that list on to the grep engine.
That should do the trick, if a map file has been generated.
Does anybody have got a better idea? Have you maybe already written some code that parses map files which you are willing to contribute? (I think there should be something in the JCL because jcldebug can use it, but I don't want to include such a large library.)
the module list is also availble in the Debug info at the bottom of the Exe file (or in TDS file)
ReplyDeleteMaybe I'm missing the point, but wouldn't it be almost as good to have checkboxes for the directory search option which were "Include Project Search Paths" and "Include Global Search Paths"? Admittedly you would pick up files not linked into your project, but it would make the grep search even better? And presumably easier to implement?
ReplyDelete(Really appreciate all your work on GExperts, thank you.)
take a look on this project
ReplyDeletehttps://github.com/tothpaul/Delphi/tree/master/DelphiTDS
Richard Stevens that would not be as useful to me, because I usually want to search only those files that are actually used in my project. But a directory search in the project and or library path might be easy to implement. I'll think about it.
ReplyDeletePaul TOTH doesn't that require the exe to contain debug information?
ReplyDeleteThomas Mueller there's a compiler option to put those info in a separate TDS file.
ReplyDeleteI miss this even more in the usage helper. Maybe there's an option I have missed?
ReplyDeleteLars Øyvind Hagland what exactly do you miss there?
ReplyDeleteThomas Mueller units in the include path does not show in the search/list unless explicitly added to the project. Precompiled libraries do though.
ReplyDelete