[Bug binutils/20337] Objdump incorrectly disassembles zero-length functions

2016-07-08 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=20337 --- Comment #2 from Alexander Ivchenko --- Created attachment 9381 --> https://sourceware.org/bugzilla/attachment.cgi?id=9381&action=edit a.out with f(), h(), g(), main having the same address -- You are receiving this mail because: You ar

[Bug binutils/20337] New: Objdump incorrectly disassembles zero-length functions

2016-07-08 Thread aivchenk at gmail dot com
Component: binutils Assignee: unassigned at sourceware dot org Reporter: aivchenk at gmail dot com Target Milestone: --- When compiling the following code: int f() {} int g() {} int h() {} int main() { return 0; } with Clang/LLVM ($clang a.cpp -O2; I used 3.7

[Bug gold/17005] [Gold] .ehframe problem with --sort-section=name

2014-06-11 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=17005 --- Comment #3 from Alexander Ivchenko --- If we assume that we applied patch from Comment 2, the resulting binary would still fails, because the .eh_frame_hdr offset table is calculated incorrectly. In Fde::write: // Tell the exception fr

[Bug gold/17005] [Gold] .ehframe problem with --sort-section=name

2014-06-01 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=17005 --- Comment #2 from Alexander Ivchenko --- Looks like in Eh_frame::set_final_data_size() output_offset is calculated incorrectly: it is always assumed that it is zero in the beginning. The following patch helped to place relocations correctly

[Bug gold/17005] [Gold] .ehframe problem with --sort-section=name

2014-05-31 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=17005 --- Comment #1 from Alexander Ivchenko --- >objdump -W a32.out a32.out: file format elf32-i386 Contents of the .eh_frame section: ZERO terminator 0004 0014 CIE Version: 1 Augmentation:

[Bug gold/17005] New: [Gold] .ehframe problem with --sort-section=name

2014-05-31 Thread aivchenk at gmail dot com
Component: gold Assignee: ian at airs dot com Reporter: aivchenk at gmail dot com CC: ccoutant at google dot com > cat a.cc void foo(void) { throw 1; } > cat b.cc void foo(void); int main() { try { foo(); } catch (int i) { return 0; } ret

[Bug gold/16945] [Gold] Executable with -fpie and -mcmodel=large gives segfault on start

2014-05-15 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=16945 --- Comment #1 from Alexander Ivchenko --- Here is where 32 bit $0xfff8 came from: x86_64.cc:3329 for R_X86_64_GOT64: -- bool have_got_offset = false; unsigned int got_offset = 0; switch (r_type) { case elfcpp::R_X86_64_

[Bug gold/16945] New: [Gold] Executable with -fpie and -mcmodel=large gives segfault on start

2014-05-14 Thread aivchenk at gmail dot com
: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: aivchenk at gmail dot com CC: ccoutant at google dot com > cat mcmodel_large.c #include #include int main() { fprintf(stdout, "Hello\n"); return 0;

[Bug gold/14324] internal error in relocate, at ../../gold/x86_64.cc:3361 with gcc -mcmodel=large

2014-05-14 Thread aivchenk at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=14324 Alexander Ivchenko changed: What|Removed |Added CC||aivchenk at gmail dot com

[Bug binutils/16317] New: [strip] strip does not preserve SHF_INFO_LINK flag for .rel.plt and erases the padding after .got.plt

2013-12-11 Thread aivchenk at gmail dot com
) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: aivchenk at gmail dot com As discussed here: https://sourceware.org/ml/binutils/2013-11/msg00315.html The testcase for SHF_INFO_LINK

[Bug gold/14948] GOLD should support ordering sections as ld does with option '--sort-section'

2013-06-06 Thread aivchenk at gmail dot com
||aivchenk at gmail dot com Resolution|--- |FIXED --- Comment #4 from Alexander Ivchenko --- This is fixed with: http://sourceware.org/ml/binutils/2013-05/msg00335.html -- You are receiving this mail because: You are on the CC list for the