[Bug binutils/14136] New: I symbol missing in nm documentation
http://sourceware.org/bugzilla/show_bug.cgi?id=14136 Bug #: 14136 Summary: I symbol missing in nm documentation Product: binutils Version: 2.22 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: marco.atz...@gmail.com Classification: Unclassified I see on an npi (libmpi.dll.a) library d002278.o: i .idata$4 i .idata$5 i .idata$6 i .idata$7 t .text U __head_cygmpi_1_dll I __imp__ompi_mpi_comm_world I __nm__ompi_mpi_comm_world but there is no "I" on the nm documentation : --- "i" For PE format files this indicates that the symbol is in a section specific to the implementation of DLLs. For ELF format files this indicates that the symbol is an indirect function. This is a GNU extension to the standard set of ELF symbol types. It indicates a symbol which if referenced by a relocation does not evaluate to its address, but instead must be invoked at runtime. The runtime execution will then return the value to be used in the relocation. "N" The symbol is a debugging symbol. --- on objdump documentation is reported: I i The symbol is an indirect reference to another symbol (I), a function to be evaluated during reloc processing (i) or a normal symbol (a space). Could nm documentation be updated, please ? -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections
http://sourceware.org/bugzilla/show_bug.cgi?id=13697 --- Comment #7 from Georg-Johann Lay 2012-05-23 19:36:45 UTC --- Created attachment 6417 --> http://sourceware.org/bugzilla/attachment.cgi?id=6417 Tentative patch: Keep .data This is a tentative patch to fix the issue by KEEPing .data. Lightly tested with a small program. Johann ld/ PR 13697 * scripttempl/avr.sc (.data): Keep it. -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14149] New: The _end symbol is not properly aligned
http://sourceware.org/bugzilla/show_bug.cgi?id=14149
Bug #: 14149
Summary: The _end symbol is not properly aligned
Product: binutils
Version: 2.22
Status: NEW
Severity: normal
Priority: P2
Component: gold
AssignedTo: i...@airs.com
ReportedBy: j...@freebsd.org
CC: ccout...@google.com
Classification: Unclassified
I have reproduced this with the gold linker from both 2.21 and 2.22. I have
reproduced this using GCC versions 4.5.3, 4.6.4, and 4.7.0 on both FreeBSD
8.2-STABLE and 9.0-STABLE. To reproduce, compile the following test program
and link with gold:
#include
#include
void foo()
{
char *c = new(std::nothrow) char[10];
delete c;
}
int
main()
{
printf("Hello world\n");
}
Use objdump -T to obtain the offset of '_end':
a.out: file format elf64-x86-64-freebsd
DYNAMIC SYMBOL TABLE:
00401ac8 gDO .bss 0008 Baseenviron
00401a80 gDO .data 0008 Base__progname
DF *UND* GLIBCXX_3.4
_ZnamRKSt9nothrow_t
DF *UND* GLIBCXX_3.4 _ZdlPv
DF *UND* FBSD_1.0atexit
DF *UND* FBSD_1.0exit
DF *UND* FBSD_1.0_init_tls
w D *UND*
_Jv_RegisterClasses
00401ad0 gDO .bss 0001 GLIBCXX_3.4 _ZSt7nothrow
DF *UND* FBSD_1.0puts
00401ad1 gD *ABS* Base_end
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.
The bug appears to be triggered by std::nothrow pulling in a reference to a 1
byte symbol at the end of the BSS.
--
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
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/14149] The _end symbol is not properly aligned
http://sourceware.org/bugzilla/show_bug.cgi?id=14149 --- Comment #1 from Cary Coutant 2012-05-23 21:59:08 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 -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14156] New: --sort-section=alignment trashes init/fini sections, and anything similar
http://sourceware.org/bugzilla/show_bug.cgi?id=14156 Bug #: 14156 Summary: --sort-section=alignment trashes init/fini sections, and anything similar Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified This bug came up from a user of musl libc (my project) building busybox (which has --sort-section=alignment in its makefile) on arm. He was experiencing crashes in busybox and nothing else, and upon examining the binary, found that the _init label (from crti.o) was getting reordered *after* the return code (from crtn.o), causing the call to _init to run off into other unrelated code. The problem has not been observed on any other systems (non-arm) with musl, nor with other libc implementations, but as far as I can tell, --sort-section=alignment is only working BY CHANCE on these systems due to the section sizes/alignments happening to keep the parts in the right order. I'm not sure what the right fix for this is, but I think the linker scripts should do something to ensure that sections which are pieced-together in a particular link order (init/fini and probably also ctors/dtors, and perhaps others) never get reordered. If that's not possible, then this option should be documented as dangerous/broken so that projects don't put it in their makefiles. -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14158] New: zero terminator in middle of .eh_frame
http://sourceware.org/bugzilla/show_bug.cgi?id=14158 Bug #: 14158 Summary: zero terminator in middle of .eh_frame Product: binutils Version: 2.23 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: amo...@gmail.com Classification: Unclassified $ powerpc64-linux-gcc -m64 -fpic -fexceptions -shared /src/tmp/hello.c $ readelf -wf a.out [snip] 003c 0014 0040 FDE cie= pc=0878..08c8 DW_CFA_advance_loc: 4 to 087c DW_CFA_register: r65 in r12 DW_CFA_advance_loc: 16 to 088c DW_CFA_restore_extended: r65 0054 ZERO terminator 0058 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 4 Data alignment factor: -8 Return address column: 65 Augmentation data: 1b DW_CFA_def_cfa: r1 ofs 0 [snip] -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14158] zero terminator in middle of .eh_frame
http://sourceware.org/bugzilla/show_bug.cgi?id=14158 Alan Modra changed: What|Removed |Added Target||powerpc64-linux Status|NEW |ASSIGNED AssignedTo|unassigned at sourceware|amodra at gmail dot com |dot org | -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14158] zero terminator in middle of .eh_frame
http://sourceware.org/bugzilla/show_bug.cgi?id=14158 --- Comment #1 from cvs-commit at gcc dot gnu.org 2012-05-24 06:20:59 UTC --- CVSROOT:/cvs/src Module name:src Changes by:amo...@sourceware.org2012-05-24 06:20:52 Modified files: bfd: ChangeLog elf64-ppc.c Log message: PR ld/14158 * elf64-ppc.c (ppc64_elf_size_stubs): Round up glink_eh_frame size to output section alignment. (ppc64_elf_build_stubs): Likewise, and extend last FDE to cover. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5711&r2=1.5712 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-ppc.c.diff?cvsroot=src&r1=1.383&r2=1.384 -- 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 https://lists.gnu.org/mailman/listinfo/bug-binutils
