This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]