Script autoloading

Script autoloading

[Jan Vrany]

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

Re: Script autoloading

[Tom Tromey]

>>>>> "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

Re: Script autoloading

[Jan Vrany]

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

Re: Script autoloading

[Tom Tromey]

>>>>> "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