Re: How to get file descriptor from abfd?

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Paul Pluzhnikov wrote:

> Currently GDB allocates memory and does a bfd_read() on dwarf debug sections.
> 
> This causes GDB to be significantly slower on low-memory machines than
> it has to be, and I have a patch to fix this by directly mmap()ing the
> debug sections instead:
> http://sourceware.org/ml/gdb-patches/2009-05/txt00023.txt
> 
> In that patch, I do:
> 
> +      caddr_t retbuf = mmap (0, map_length, PROT_READ, MAP_PRIVATE,
> +			     fileno ((FILE *)abfd->iostream),
> +			     pg_offset);
> 
> and this cast of abfd->iostream has been flagged as possibly un-kosher.
> 
> What is the proper way to get access to the underlying file descriptor
> for a given abfd (if there is one)?
> If there isn't a way, should there be?

  It's a bad idea, because anything you do to that FILE* might confuse the
underlying bfd_iovec stream.  The cleanest design would be to add an mmap
member function to bfd_iovec.

> I would have used bfd_get_file_window(), but it's only compiled in
> when --use-mmap was given to bfd/configure.
> 
> Is there a way to turn that on for GDB?

  Just configure with it.  It will be passed to the included bfd/ configure.

> Is it ok to do this:
> 
>   if ((abfd->flags & BFD_IN_MEMORY) == 0) ...
> 
> in gdb/dwarf2read.c?

  Won't be necessary if you do it the iovec way, there will just be a stub
implementation of 'bmmap()' for in-memory iovecs and a real one (conditioned
on HAVE_MMAP) for file-based iovecs.  Then gdb can call the bfd_mmap wrapper
function speculatively and just fall back to the old way of doing it if that
returns an error code.

    cheers,
      DaveK