> I do not know if I will have the time. But from whatever time I have, > I'll set some apart to help you make a package interface. > Then you can > provide it as yours, and maintain it yourself. >
The patch is 18 lines of new code. I have attached it. The difficulty was not writing the code but figure out where to put it. This mail exchange has taken more time and lines written than writing the patch (note that I don't mind). I'm perfectly happy sharing it this way. The users that would benefit from it would know how to apply a patch. Don't make a package interface for 18 lines of code, please. > >> I guess the address breakpoint could be extended to take > symbol names > >> too. > >> > > Still need to know the exact spelling of the symbol. The > same symbol > > can be uppercase or "original" case, sometimes depending on > wheter you > > have debug info or not (exported symbol). Plus the name > mangling for > > class methods. > > Example: procedure _FPC_WinMainCRTStartup;stdcall;public name > > '_WinMainCRTStartup'; is known to the debugger as > _FPC_WINMAINCRTSTARTUP > > (stabs info available). I find myself using 'info function' > frequently to > > find or disambiguate functions. > > > > But thats beside the point? using a watch or the commandline => the > question of needing the address or name is the same. This was about extending the address breakpoint to take symbol names. My point is that taking a symbol name assumes you know the symbol name, spelled correctly, or you provide a way to look it up: a front end to 'info function'. With all the exported symbols from windows dll's I wonder if the average user would be able to do whatsoever with such an interface. So the comment was in the same line as the previous ones: is this worth the effort? Thanks, Ludo
gdb.diff
Description: Binary data
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
