* Script autoloading @ 2018-08-01 6:21 Jan Vrany 2018-08-08 14:43 ` Tom Tromey 0 siblings, 1 reply; 4+ messages in thread From: Jan Vrany @ 2018-08-01 6:21 UTC (permalink / raw) To: gdb Hi there, I have a project that makes use of a shared library, say librun.so. That library is part of the project and there's extensive python script to support debugging. This python script is named librun.so-gdb.py so and is located along librun.so. Thi way. GDB loads automatically. Works perfect, no extra setup (other autoload-safe path). However, I struggle to make this working also on Windows, where the library is named "librun.dll", not "librun.so'. I thought I'd use .debug_gdb_scripts section as described in GDB manual, but this does not work very good since $cdir is not searched in that case. Any idea how to make it working on both, Linux and Windows with no additional setup (other than autoload-safe path)? What's is the rationale for excluding $cdir from source directories when searching for scipts? Thanks. Best, Jan ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Script autoloading 2018-08-01 6:21 Script autoloading Jan Vrany @ 2018-08-08 14:43 ` Tom Tromey 2018-08-15 8:09 ` Jan Vrany 0 siblings, 1 reply; 4+ messages in thread From: Tom Tromey @ 2018-08-08 14:43 UTC (permalink / raw) To: Jan Vrany; +Cc: gdb >>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes: Jan> However, I struggle to make this working also on Windows, where the Jan> library is named "librun.dll", not "librun.so'. Jan> I thought I'd use .debug_gdb_scripts section as described in Jan> GDB manual, but this does not work very good since $cdir is Jan> not searched in that case. Jan> Any idea how to make it working on both, Linux and Windows with Jan> no additional setup (other than autoload-safe path)? What's is the Jan> rationale for excluding $cdir from source directories when searching Jan> for scipts? I don't know why $cdir isn't searched, other than what the manual says: If the entry specifies a file, GDB will look for the file first in the current directory and then along the source search path (*note Specifying Source Directories: Source Path.), except that '$cdir' is not searched, since the compilation directory is not relevant to scripts. This doesn't really explain it to me, though, since the compilation directory is used to find sources. Why can't you just rename the file at install time, depending on what the library is called? It seems like your build system is already doing that for the library itself. Tom ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Script autoloading 2018-08-08 14:43 ` Tom Tromey @ 2018-08-15 8:09 ` Jan Vrany 2018-09-04 18:22 ` Tom Tromey 0 siblings, 1 reply; 4+ messages in thread From: Jan Vrany @ 2018-08-15 8:09 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb On Wed, 2018-08-08 at 08:42 -0600, Tom Tromey wrote: > > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes: > > Jan> However, I struggle to make this working also on Windows, where the > Jan> library is named "librun.dll", not "librun.so'. > > Jan> I thought I'd use .debug_gdb_scripts section as described in > Jan> GDB manual, but this does not work very good since $cdir is > Jan> not searched in that case. > > Jan> Any idea how to make it working on both, Linux and Windows with > Jan> no additional setup (other than autoload-safe path)? What's is the > Jan> rationale for excluding $cdir from source directories when searching > Jan> for scipts? > > I don't know why $cdir isn't searched, other than what the manual says: > > If the entry specifies a file, GDB will look for the file first in the > current directory and then along the source search path (*note > Specifying Source Directories: Source Path.), except that '$cdir' is not > searched, since the compilation directory is not relevant to scripts. > > This doesn't really explain it to me, though, since the compilation > directory is used to find sources. I was thinking exactly that when I read it. > > Why can't you just rename the file at install time, depending on what > the library is called? It seems like your build system is already doing > that for the library itself. The build system does not rename the library itself, on Linux (*BSD) the compilation produces librun.so, on windows librun.dll. I can indeed rename it during build, but this is bit awkward for development (for deployment it's just fine). The problem is that if on Windows I rename it, I'd have two different files (librun.so-gdb.py and librun.dll-gdb.py) with same contents (this is not a problem). When developing debugging scripts, I'd have to edit the latter (librun.dll-gdb.py) and then *not to forget* to copy changes back and commit. Moreover, this copied librun.dll-gdb.py would either always show up in "git status" as a new file or - if I add it to .gitignore, - won't show up at all which would make it more likely that I'd forgot to copy changes back an commit. As you see, it's doable for sure but rather inconvenient. Adding $cdir would solve this problem. The documentation also says: For object files using .exe suffix GDB tries to load first the scripts normally according to its .exe filename. But if no scripts are found GDB also tries script filenames matching the object file without its .exe suffix. This .exe stripping is case insensitive and it is attempted on any platform. This makes the script filenames compatible between Unix and MS-Windows hosts. Maybe we can have similar automagic for .so / .dll / .dylib extensions. I'm ready to write a patch and submit it, unless there's a reason for current behavior. Jan > > Tom ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Script autoloading 2018-08-15 8:09 ` Jan Vrany @ 2018-09-04 18:22 ` Tom Tromey 0 siblings, 0 replies; 4+ messages in thread From: Tom Tromey @ 2018-09-04 18:22 UTC (permalink / raw) To: Jan Vrany; +Cc: Tom Tromey, gdb >>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes: Sorry for not responding to this earlier. Jan> Any idea how to make it working on both, Linux and Windows with Jan> no additional setup (other than autoload-safe path)? What's is the Jan> rationale for excluding $cdir from source directories when searching Jan> for scipts? [...] Jan> Adding $cdir would solve this problem. The documentation also says: Jan> For object files using .exe suffix GDB tries to load first the Jan> scripts normally according to its .exe filename. But if no scripts Jan> are found GDB also tries script filenames matching the object Jan> file without its .exe suffix. This .exe stripping is case Jan> insensitive and it is attempted on any platform. This makes the Jan> script filenames compatible between Unix and MS-Windows hosts. Jan> Maybe we can have similar automagic for .so / .dll / .dylib Jan> extensions. Jan> I'm ready to write a patch and submit it, unless there's a reason for Jan> current behavior. I couldn't think of a reason, so why not go ahead. The only risk you have is of someone thinking of a reason during patch review, Tom ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-09-04 18:22 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-01 6:21 Script autoloading Jan Vrany 2018-08-08 14:43 ` Tom Tromey 2018-08-15 8:09 ` Jan Vrany 2018-09-04 18:22 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).