PR 2014, 2007, 1968, 1945, 1935, 1865, 1823

PR 2014, 2007, 1968, 1945, 1935, 1865, 1823

[Alan Modra]

I believe that the gdb PRs listed in the subject should have been fixed
by recent changes to BFD.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PR 2014, 2007, 1968, 1945, 1935, 1865, 1823

[Daniel Jacobowitz]

On Thu, Oct 27, 2005 at 10:44:11AM +0930, Alan Modra wrote:
> I believe that the gdb PRs listed in the subject should have been fixed
> by recent changes to BFD.

Thank you, Alan!  That's been on my list for ages.

I'm not sure they're fixed - I need to make sure that GDB doesn't fall
down in other ways now that BFD no longer aborts - but I'm sure we can
take it from here.

Oh, while you're in the area: ISTR finding that BFD was missing
O_LARGEFILE somewhere that GDB had it.  So if GDB opened the core file,
and then BFD closed and reopened it, the open would fail.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PR 2014, 2007, 1968, 1945, 1935, 1865, 1823

[Alan Modra]

On Wed, Oct 26, 2005 at 10:01:24PM -0400, Daniel Jacobowitz wrote:
> Oh, while you're in the area: ISTR finding that BFD was missing
> O_LARGEFILE somewhere that GDB had it.  So if GDB opened the core file,
> and then BFD closed and reopened it, the open would fail.

Yes, there was a silly check in bfd_cache_lookup_worker that tested for
abfd->where being in unsigned long range.  That's gone, but I guess
there might be other places similarly broken.

I'm also working on the following tweaks to bfd_cache_lookup.

/* In some cases we can optimize cache operation when reopening files.
   For instance, a flush is entirely unnecessary if the file is already
   closed, so a flush would use CACHE_NO_OPEN.  Similarly, a seek using
   SEEK_SET or SEEK_END need not first seek to the current position.
   For stat we ignore seek errors, because stat might be used (eg. by
   gdb) to determine whether a file has changed while we weren't
   looking.  If it has, then it's possible that the new file is shorter
   and we don't want a seek error to prevent us doing the stat.  */ 
enum cache_flag {
  CACHE_NORMAL = 0,
  CACHE_NO_OPEN = 1,
  CACHE_NO_SEEK = 2,
  CACHE_NO_SEEK_ERROR = 4
};

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PR 2014, 2007, 1968, 1945, 1935, 1865, 1823

[Daniel Jacobowitz]

On Thu, Oct 27, 2005 at 12:20:52PM +0930, Alan Modra wrote:
> On Wed, Oct 26, 2005 at 10:01:24PM -0400, Daniel Jacobowitz wrote:
> > Oh, while you're in the area: ISTR finding that BFD was missing
> > O_LARGEFILE somewhere that GDB had it.  So if GDB opened the core file,
> > and then BFD closed and reopened it, the open would fail.
> 
> Yes, there was a silly check in bfd_cache_lookup_worker that tested for
> abfd->where being in unsigned long range.  That's gone, but I guess
> there might be other places similarly broken.

No, I meant this literally: gdb/corelow.c:bfd_open uses O_LARGEFILE,
and nothing in BFD does.  This means that BFD can't open 4GB files on
some 32-bit environments.

-- 
Daniel Jacobowitz
CodeSourcery, LLC