[Bug binutils/28714] New: Some tools (e.g. size) deliberately omitted from "tooldir" installation
https://sourceware.org/bugzilla/show_bug.cgi?id=28714 Bug ID: 28714 Summary: Some tools (e.g. size) deliberately omitted from "tooldir" installation Product: binutils Version: 2.38 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: stefan.bru...@rwth-aachen.de Target Milestone: --- Only some of the built tools are installed into the $tooldir: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/Makefile.am;hb=d8bbdb9dd5653716b0f904bba69ca5b63acaca2d#l111 Most notably, "size" is omitted, but also addr2line, elfedit, gprof and strings. Whats the rationale which program also gets the symlink in the $tooldir, and which is only installed into $bindir? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28714] Some tools (e.g. size) deliberately omitted from "tooldir" installation
https://sourceware.org/bugzilla/show_bug.cgi?id=28714 Stefan Brüns changed: What|Removed |Added See Also||https://bugzilla.suse.com/s ||how_bug.cgi?id=1185712 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28714] Some tools (e.g. size) deliberately omitted from "tooldir" installation
https://sourceware.org/bugzilla/show_bug.cgi?id=28714 --- Comment #1 from Andreas Schwab --- Those are the tools needed by gcc or gdb, see ACX_CHECK_INSTALLED_TARGET_TOOL in the toplevel configure. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/13256] AR + plugin fails with "no operation specified" error
https://sourceware.org/bugzilla/show_bug.cgi?id=13256 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |2.33 CC||pinskia at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28709] [RISC-V] a unused section can't be removed with -gc-sections
https://sourceware.org/bugzilla/show_bug.cgi?id=28709 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-20 --- Comment #1 from Alan Modra --- The problem is actually that you have out-of-order relocations in .eh_frame. Relocation section '.rela.eh_frame' at offset 0x538 contains 8 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 001c 00080039 R_RISCV_32_PCREL .L0 + 0 0020 000c0023 R_RISCV_ADD32 003e .L0 + 0 0020 00080027 R_RISCV_SUB32 .L0 + 0 0040 000f0039 R_RISCV_32_PCREL .L0 + 0 0044 00110023 R_RISCV_ADD32 0002 .L0 + 0 0044 000f0027 R_RISCV_SUB32 .L0 + 0 002f 000b0035 R_RISCV_SET6 003a .L0 + 0 002f 000a0034 R_RISCV_SUB6 0006 .L0 + 0 When the linker is marking the FDE for _GLOBAL__sub_I__ZN3Box3getEv it starts correctly at the r_offset 0x40 reloc marking that and the two r_offset 0x44 relocs. Those all point at _GLOBAL__sub_I__ZN3Box3getEv. (Watch out for tricky multiple .L0 symbols, it's easy to get confused over which section they belong to! You need to look at the index in r_info.) Then the two out-of-order relocs at 0x2f are encountered, and processed as if they are part of the _GLOBAL__sub_I__ZN3Box3getEv FDE. Those particular .L0s are defined in .text.test11, which is why .text.test11 is marked as needed. Disabling .eh_frame marking is *not* the solution. You should figure out why the assembler is generating relocs out-of-order and fix that. -- You are receiving this mail because: You are on the CC list for the bug.
