Using separate debug info files with Windows DLLs

Using separate debug info files with Windows DLLs

[Eli Zaretskii]

Does the "debug link" method work with Windows DLLs produces by MinGW
GCC and GNU Binutils?

The "Separate Debug Files" node of the GDB manual talks only about
executables, and doesn't mention shared libraries.  If those methods
are supposed to work with shared libraries in general, and Windows
DLLs in particular, then I wonder (a) would the Windows loader live in
peace with the additional .gnu_debuglink section that needs to be put
there, and (b) when will GDB load the debug info using this method?

My use case is that I have an installed DLL which is stripped of its
symbols, but I need some of the debug information from the library to
display opaque data structures the library exposes to the calling
applications.

Thanks in advance for any help.

Re: Using separate debug info files with Windows DLLs

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Does the "debug link" method work with Windows DLLs produces by MinGW
Eli> GCC and GNU Binutils?

I think so.

Eli> The "Separate Debug Files" node of the GDB manual talks only about
Eli> executables, and doesn't mention shared libraries.  If those methods
Eli> are supposed to work with shared libraries in general, and Windows
Eli> DLLs in particular, then I wonder (a) would the Windows loader live in
Eli> peace with the additional .gnu_debuglink section that needs to be put
Eli> there, and (b) when will GDB load the debug info using this method?

I don't know the answer to (a), but for (b), as far as I know,
coff_symfile_read is used for both executables and libraries; and at the
end of coff_symfile_read it has code to read the debug link and find the
separate debug file.  This is done if the main objfile doesn't have any
debug info:

  /* Try to add separate debug file if no symbols table found.   */
  if (!objfile_has_partial_symbols (objfile))
    {
[...]



I wonder if the build-id approach could be extended to COFF somehow.
build-ids are better because they don't require the slow CRC
computation.

Tom

Re: Using separate debug info files with Windows DLLs

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: gdb@sourceware.org
> Date: Sun, 19 Aug 2018 10:40:34 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Does the "debug link" method work with Windows DLLs produces by MinGW
> Eli> GCC and GNU Binutils?
> 
> I think so.
> 
> Eli> The "Separate Debug Files" node of the GDB manual talks only about
> Eli> executables, and doesn't mention shared libraries.  If those methods
> Eli> are supposed to work with shared libraries in general, and Windows
> Eli> DLLs in particular, then I wonder (a) would the Windows loader live in
> Eli> peace with the additional .gnu_debuglink section that needs to be put
> Eli> there, and (b) when will GDB load the debug info using this method?
> 
> I don't know the answer to (a), but for (b), as far as I know,
> coff_symfile_read is used for both executables and libraries; and at the
> end of coff_symfile_read it has code to read the debug link and find the
> separate debug file.  This is done if the main objfile doesn't have any
> debug info:
> 
>   /* Try to add separate debug file if no symbols table found.   */
>   if (!objfile_has_partial_symbols (objfile))
>     {
> [...]

Thanks, I will try to use this some time.

> I wonder if the build-id approach could be extended to COFF somehow.

That would be nice, yes.