http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #6 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-03
15:19:05 UTC ---
> --- Comment #4 from Ian Lance Taylor <ian at airs dot com> 2011-03-02
> 06:03:01 UTC ---
> It is possible that gdb is misleading in saying <Address NNN out of bounds>.
> I
> don't know. The address should be allocated via the call to mmap in
It's not: I've checked the address against the pmap output and that part
of the address space is indeed not mapped.
> Output_file::map_no_anonymous called indirectly from Output_file::open.
I see: I've set a breakpoint there and upon the first call, ::mmap
returns
(gdb) p base
$20 = (void *) 0xfe4c1000
but
(gdb) p this->base_
$21 = (unsigned char *) 0xfe4c1000 <Address 0xfe4c1000 out of bounds>
and pmap indicates that this address is not mapped.
It turns out that this is called for the output file:
(gdb) p this->o_
$26 = 114
and with pfiles -F, I see
114: S_IFREG mode:0755 dev:171,65630 ino:1165706 uid:2110 gid:4620 size:0
O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE FD_CLOEXEC
/vol/gcc/obj/regression/trunk/11-gcc-gas-gold/build/i386-pc-solaris2.11/libgcc/libgcc_s.so.1.tmp
offset:0
Maybe the bug is related to this section in mmap(2):
The mmap() function allows [pa, pa + len) to extend beyond
the end of the object both at the time of the mmap() and
while the mapping persists, such as when the file is created
prior to the mmap() call and has no contents, or when the
file is truncated. Any reference to addresses beyond the end
of the object, however, will result in the delivery of a
SIGBUS or SIGSEGV signal. The mmap() function cannot be used
to implicitly extend the length of files.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
