Summary: | The _end symbol is not properly aligned | ||
---|---|---|---|
Product: | binutils | Reporter: | jhb |
Component: | gold | Assignee: | Ian Lance Taylor <ian> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | ccoutant, ppluzhnikov |
Priority: | P2 | ||
Version: | 2.22 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
jhb
2012-05-23 21:38:50 UTC
> Note that _end has a mis-aligned address. This causes jemalloc (the malloc in
> FreeBSD's libc) to corrupt it's internal RB trees as it assumes the start of
> the heap is aligned on at least an even address. Using ld.bfd results in _end
> being aligned on an 8-byte boundary. The linker scripts for ld.bfd for FreeBSD
> explicitly pad _end to an 8 byte boundary, so I assume it is a bug for the gold
> linker to not do this.
Not that I'm arguing the linker shouldn't do this, but I can't find
anything in the x86 ABI or the AMD64 ABI documents that guarantee _end
should have any specific alignment. The AMD64 ABI supplement says
nothing about _end, and the Intel386 Sys V ABI supplement says only
this:
extern _end;
This symbol refers neither to a routine nor to a location with interesting
contents. Instead, its address must correspond to the beginning of a
program’s dynamic allocation area, called the heap. Typically, the heap
begins immediately after the data segment of the program’s
executable file.
It seems to me that your malloc implementation is relying on a
behavior of the GNU linker that is not guaranteed by the ABI. Even if
we do change gold to match the GNU ld behavior, I'd still recommend
that you change the implementation to rely only on the documented ABI.
-cary
That's fair. In fact, the man pages for end(3) and sbrk(2) on FreeBSD do not make any claims at all about alignment. POSIX intentionally states that sbrk(2) return values do not enforce any alignment (http://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html). The previous malloc implementation in FreeBSD did use rounding on the return value from sbrk(0) (so it would have worked fine). I will work on getting jemalloc fixed both in FreeBSD and upstream. I'm fine with having this closed on my end. Up to you if you think there might be any other software that depends on this behavior of GNU ld. FYI, jemalloc has since been fixed to handle unaligned _end addresses. Given the link in my last comment about POSIX not requiring any specific alignment from sbrk(), I think you can probably close this as not being a bug. (Apparently) not a Gold bug. |