Re: [PATCH v2 3/4] Add DWARF index cache

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 27 Jul 2018 10:01:43 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
> 
> On 2018-07-27 05:06, Eli Zaretskii wrote:
> >> From: Simon Marchi <simon.marchi@ericsson.com>
> >> CC: Simon Marchi <simon.marchi@ericsson.com>
> >> Date: Wed, 25 Jul 2018 18:47:03 -0400
> >> 
> >> GDB can generate indexes for DWARF debug information, which, when
> >> integrated in the original binary, can speed up loading object files.
> >> This can be done using the gdb-add-index script or directly by the
> >> linker itself.
> > 
> > The information in the last sentence is not mentioned in the
> > documentation patch you provided.  I think we should mention that.
> 
> I think this is already well covered by the rest of the "18.5 Index 
> Files Speed Up GDB" section, just before the content I added, isn't it?

Ah, yes, you are right.

> >> - The saved index file is exactly the same as the output of the "save
> >>   gdb-index" command.  It is therefore the exact same content that 
> >> would
> >>   be found in the .gdb_index or .debug_names section.  We just leave 
> >> it
> >>   as a standalone file instead of merging it in the binary.
> > 
> > This should be mentioned in the documentation, IMO.
> 
> Ok, I thought this was an internal GDB implementation detail (which 
> could be subject to change), but I can add it if you think it is 
> important.

If we think this details is likely to change, or have other good
reasons not divulge this, I'm okay with keeping silent about it.  But
if chances are this will stay forever (or thereabouts), I think the
details is important enough to tell the users.

> >> +      /* If we get EEXIST and the existing path is a directory, then 
> >> we're
> >> +         happy.  If it exists, but it's a regular file and this is 
> >> not the last
> >> +         component, we'll fail at the next component.  If this is the 
> >> last
> >> +         component, the caller will fail with ENOTDIR when trying to
> >> +         open/create a file under that path.  */
> >> +      if (mkdir (start, 0700) != 0)
> > 
> > This will not work on Windows.
> 
> Which part of it?

mkdir accepts only one argument, not 2.

> > Does this mean this feature will only work on systems with mmap?
> 
> Indeed.  There is an equivalent API for Windows though I think:
> 
> https://docs.microsoft.com/en-us/windows/desktop/Memory/file-mapping
> 
> I can't really do the Windows bits, because I just don't have the 
> competence to write software for Windows.  Every time I tried to build 
> GDB for Windows, I failed miserably (do we have a guide for that?).  So 
> my thought (including for the mkdir_recursive function) was that 
> somebody who used Windows could later implement the missing parts.  

Fair enough.

> Also, I guess that somebody debugging native executables on Windows 
> wouldn't have a use for the cache, because indices only work for DWARF 
> debug info.

MinGW uses DWARF debug info for quite a few years now, so caching will
definitely be useful.

Thanks.