This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Fix bfd_read to cope with bad BIMs
- To: law at cygnus dot com
- Subject: Re: Fix bfd_read to cope with bad BIMs
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 21 Jan 2000 15:54:06 -0500
- CC: dj at delorie dot com, nickc at cygnus dot com, binutils at sourceware dot cygnus dot com
- References: <12259.948486249@upchuck>
Date: Fri, 21 Jan 2000 13:24:09 -0700
From: Jeffrey A Law <law@cygnus.com>
In message <200001212018.PAA08202@envy.delorie.com>you write:
>
> > The patch below fixes a small bug in bfd_read(). If a bfd_in_memory
> > structure has a "size" field that is less than the value of
> > "abfd->where" then the code would attempt to memcpy() a negative sized
> > amount of data, resulting in a segmentation fault.
>
> Note that bfd_in_memory support is very weak and many aspects of it
> fail. While it's good to fix these bugs, beware of a false sense of
> security. It barely worked enough for the dll stuff I added back
> when, and that was after I added support for things I needed it to do.
It's marginal. The biggest problem is mistakes in creating in-memory
sections will tend to stomp on important things.
FWIW, most native ports are using in-memory section support to build up
plt, dlt, stubs, etc for dynamic linking. So while it may be somewhat
fragile, it's not terrible.
Actually, you're thinking of SEC_IN_MEMORY, not BFD_IN_MEMORY.
BFD_IN_MEMORY was a quick hack to support compressed files in archives
in Digital Unix, which DJ then extended for his DLL work.
Ian