This is the mail archive of the
mailing list for the binutils project.
Re: bfd_mmap for archive members
On Nov 18, 2009, at 7:18 PM, John Reiser wrote:
> On 11/18/2009 06:45 AM, Tristan Gingold wrote:
>> currently bfd_mmap does nothing particular with archive members, ie it doesn't add the member offset in the
>> archive to the offset argument. This is not the behaviour of bfd_seek (which handles archive members).
>> I today hit this issue because gdb/dwarf2read.c uses bfd_mmap to read dwarf and because Darwin has fat
>> binaries, the bfd may be a archive member.
>> I don't think that we can fix bfd_mmap because gdb/dwarf2read.c does address arithmetic with the offset to
>> align it to a page. Adding member offset would invalidate this calculation. Maybe the interface of bfd_mmap
>> was not designed for member but I suppose it is too late to change it.
> It depends on the purpose for which dwarf2read.c does the alignment, and what it expects
> of the mapped address. If the only reason for alignment is to make mmap() *possible*
> [that is, to choose (0xfff & memory_address) == (0xfff & file_offset)], and if dwarf2read.c
> does not care that the low-order 12 bits of the result might not be zero, and if the mapping
> is MAP_PRIVATE [changes to memory are not written back to the file], then it should be possible
> to interpret the request as "Please map an interval of the file into memory, so that this
> member is completely contained in the mapped interval, and return the address of the
> beginning of the member. I promise not to scribble on anything that matters."
Yes, it aligns to make mmap possible and correctly handles offset in the page.
> [It is conceivable that dwarf2read.c might currently "try too hard",
> and might need some adjustment to handle the implementation of bfd_mmap.]
>> I plan to post a path on gdb-patches to fix this issue but I'd like to have a confirmation that this is
>> the right way to do it. If so I also plan to improve the documentation for bfd_mmap to make the handling
>> of archive members clearer.
> These three threads in the last six months have 'bfd_mmap'. How does the proposal
> relate to them?
I didn't realize that bfd_mmap was added that recently and maybe we could slightly change the interface.