[Bug ld/30343] LTO ignores linker reference to _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 --- Comment #5 from Pali Rohár --- Hello! I have test proposed fix and it works fine. Both LTO and non-LTO versions are correctly generated. Also everything is working fine when there is no psuedo reloc and _pei386_runtime_relocator() is not defined/compiled at all. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 57042 in oss-fuzz: binutils:fuzz_objdump: Crash in print_insn
Updates: Labels: -restrict-view-commit Comment #3 on issue 57042 by sheriffbot: binutils:fuzz_objdump: Crash in print_insn https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57042#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 57050 in oss-fuzz: binutils:fuzz_disassemble: Crash in print_insn
Updates: Labels: -restrict-view-commit Comment #3 on issue 57050 by sheriffbot: binutils:fuzz_disassemble: Crash in print_insn https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57050#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 57041 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_i386: Crash in print_insn
Updates: Labels: -restrict-view-commit Comment #3 on issue 57041 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_i386: Crash in print_insn https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57041#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/30343] LTO ignores linker reference to _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 --- Comment #4 from Alan Modra --- Created attachment 14864 --> https://sourceware.org/bugzilla/attachment.cgi?id=14864=edit possible fix -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29763] [docs] The user guide needs to be expanded
https://sourceware.org/bugzilla/show_bug.cgi?id=29763 --- Comment #1 from Ruud van der Pas --- The recent changes committed upstream are a big step forward. Many more options have been documented now. The index lists most of the commands and options, and the text of all man pages is included in the user guide. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29521] [docs] man pages are not in the release tarball
https://sourceware.org/bugzilla/show_bug.cgi?id=29521 Ruud van der Pas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Ruud van der Pas --- The dependence on help2man has been eliminated. All man pages are generated using Texinfo. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29759] [display html] Support for aarch64 is needed
https://sourceware.org/bugzilla/show_bug.cgi?id=29759 Ruud van der Pas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Ruud van der Pas --- The dependence on help2man has been eliminated. All man pages are now generated using Texinfo. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29521] [docs] man pages are not in the release tarball
https://sourceware.org/bugzilla/show_bug.cgi?id=29521 --- Comment #9 from Ruud van der Pas --- I think this bug has been addressed and resolved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nick Clifton --- (In reply to Torbjörn SVENSSON from comment #9) Hi Torbjörn > > if (!cmse_sec->gc_mark > > && !_bfd_elf_gc_mark (info, cmse_sec, > > gc_mark_hook)) > > return false; > > /* The debug sections related to these secure entry > > functions are marked on enabling below flag. */ > > debug_sec_need_to_be_marked = true; > > break; > Is it correct to break the for-loop here? > When the break statement is there, then only the first entry in the > sym_hashes array that matches the CMSE_PREFIX criteria will passed on to the > _bfd_elf_gc_mark function. Isn't it required to call this function for every > cmse_sec value or would it be enough with just the first value? You are correct. That was another mistake. I have fixed that too and checked in the patch. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 --- Comment #10 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e4fbcd83c2423221ddde99d50b432df7dda06f5f commit e4fbcd83c2423221ddde99d50b432df7dda06f5f Author: Nick Clifton Date: Fri May 5 11:11:32 2023 +0100 Debug info is lost for functions only called from functions marked with cmse_nonsecure_entr PR 30354 * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354
--- Comment #9 from Torbjörn SVENSSON ---
@Nick: I've been trying to understand what you patch does and come up with a
few questions.
Below is the full function, with your patch applied, with my questions/comments
inline.
> static bool
> elf32_arm_gc_mark_extra_sections (struct bfd_link_info *info,
> elf_gc_mark_hook_fn gc_mark_hook)
> {
> bfd *sub;
> Elf_Internal_Shdr **elf_shdrp;
> asection *cmse_sec;
> obj_attribute *out_attr;
> Elf_Internal_Shdr *symtab_hdr;
> unsigned i, sym_count, ext_start;
> const struct elf_backend_data *bed;
> struct elf_link_hash_entry **sym_hashes;
> struct elf32_arm_link_hash_entry *cmse_hash;
> bool again, is_v8m, first_bfd_browse = true;
> bool extra_marks_added = false;
> asection *isec;
>
> _bfd_elf_gc_mark_extra_sections (info, gc_mark_hook);
>
> out_attr = elf_known_obj_attributes_proc (info->output_bfd);
> is_v8m = out_attr[Tag_CPU_arch].i >= TAG_CPU_ARCH_V8M_BASE
>&& out_attr[Tag_CPU_arch_profile].i == 'M';
>
> /* Marking EH data may cause additional code sections to be marked,
> requiring multiple passes. */
> again = true;
> while (again)
> {
> again = false;
> for (sub = info->input_bfds; sub != NULL; sub = sub->link.next)
> {
> asection *o;
>
> if (! is_arm_elf (sub))
> continue;
>
> elf_shdrp = elf_elfsections (sub);
> for (o = sub->sections; o != NULL; o = o->next)
> {
> Elf_Internal_Shdr *hdr;
>
> hdr = _section_data (o)->this_hdr;
> if (hdr->sh_type == SHT_ARM_EXIDX
> && hdr->sh_link
> && hdr->sh_link < elf_numsections (sub)
> && !o->gc_mark
> && elf_shdrp[hdr->sh_link]->bfd_section->gc_mark)
> {
> again = true;
> if (!_bfd_elf_gc_mark (info, o, gc_mark_hook))
> return false;
> }
> }
>
> /* Mark section holding ARMv8-M secure entry functions. We mark all
> of them so no need for a second browsing. */
> if (is_v8m && first_bfd_browse)
> {
> bool debug_sec_need_to_be_marked = false;
>
> sym_hashes = elf_sym_hashes (sub);
> bed = get_elf_backend_data (sub);
> symtab_hdr = _tdata (sub)->symtab_hdr;
> sym_count = symtab_hdr->sh_size / bed->s->sizeof_sym;
> ext_start = symtab_hdr->sh_info;
>
> /* Scan symbols. */
> for (i = ext_start; i < sym_count; i++)
> {
> cmse_hash = elf32_arm_hash_entry (sym_hashes[i -
> ext_start]);
>
> /* Assume it is a special symbol. If not, cmse_scan will
> warn about it and user can do something about it. */
> if (startswith (cmse_hash->root.root.root.string,
> CMSE_PREFIX))
> {
> cmse_sec = cmse_hash->root.root.u.def.section;
> if (!cmse_sec->gc_mark
> && !_bfd_elf_gc_mark (info, cmse_sec, gc_mark_hook))
> return false;
> /* The debug sections related to these secure entry
> functions are marked on enabling below flag. */
> debug_sec_need_to_be_marked = true;
> break;
Is it correct to break the for-loop here?
When the break statement is there, then only the first entry in the sym_hashes
array that matches the CMSE_PREFIX criteria will passed on to the
_bfd_elf_gc_mark function. Isn't it required to call this function for every
cmse_sec value or would it be enough with just the first value?
> }
> }
>
> if (debug_sec_need_to_be_marked)
> {
> /* Looping over all the sections of the object file
> containing
> Armv8-M secure entry functions and marking all the debug
> sections. */
> for (isec = sub->sections; isec != NULL; isec = isec->next)
> {
> /* If not a debug sections, skip it. */
> if (!isec->gc_mark && (isec->flags & SEC_DEBUGGING))
> {
> isec->gc_mark = 1;
> extra_marks_added = true;
> }
> }
> debug_sec_need_to_be_marked = false;
Since the scope of the "debug_sec_need_to_be_marked" variable is now much
smaller, I think this line should be removed.
> }
> }
> }
>
> first_bfd_browse = false;
> }
>
> /* PR
[Bug ld/30422] or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large
https://sourceware.org/bugzilla/show_bug.cgi?id=30422 Luca Bonissi changed: What|Removed |Added CC||gcc at scarsita dot it -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30422] New: or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large
https://sourceware.org/bugzilla/show_bug.cgi?id=30422 Bug ID: 30422 Summary: or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=large Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: gcc at scarsita dot it Target Milestone: --- Created attachment 14863 --> https://sourceware.org/bugzilla/attachment.cgi?id=14863=edit Patch to pre-scan the presence of R_OR1K_GOT_AHI16 to detect -mcmodel=large usage While compiling ghostscript shared library with -mcmodel=large on or1k, there is still the GOT overflow error: ./soobj/gxdevndi.o: in function `gx_devn_reduce_colored_halftone': gxdevndi.c:(.text+0x7c): relocation truncated to fit: R_OR1K_GOT16 against symbol `fc_color_quo' defined in .data.rel.ro.local section in ./soobj/gxdevndi.o ./soobj/gxblend.o: in function `art_blend_pixel_8_inline': gxblend.c:(.text+0x1954): relocation truncated to fit: R_OR1K_GOT16 against symbol `art_blend_sq_diff_8' defined in .rodata section in ./soobj/gxblend.o This is because in some case gcc place R_OR1K_GOT_AHI16 *after* R_OR1K_GOT16, so ld does not detected the overflow handling: gxdevndi.o: file format elf32-or1k RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 004c R_OR1K_GOTPC_HI16 _GLOBAL_OFFSET_TABLE_-0x0004 0050 R_OR1K_GOTPC_LO16 _GLOBAL_OFFSET_TABLE_ 007c R_OR1K_GOT16 fc_color_quo 00dc R_OR1K_GOT_AHI16 fc_color_quo 014c R_OR1K_GOT_AHI16 gx_dc_type_pure 015c R_OR1K_GOT16 gx_dc_type_pure 0260 R_OR1K_GOT_AHI16 gx_dc_type_ht_binary 0270 R_OR1K_GOT16 gx_dc_type_ht_binary 02d8 R_OR1K_GOT_AHI16 fc_color_quo 02e8 R_OR1K_GOT16 fc_color_quo [...] gxblend.o: file format elf32-or1k RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 1530 R_OR1K_GOTPC_HI16 _GLOBAL_OFFSET_TABLE_-0x0004 1534 R_OR1K_GOTPC_LO16 _GLOBAL_OFFSET_TABLE_ 17ac R_OR1K_GOTOFF_AHI16 .rodata.str1.1 17b8 R_OR1K_PLT26 memcpy 18f0 R_OR1K_GOTOFF_LO16 .rodata.str1.1 18f4 R_OR1K_PLT26 dprintf_file_and_line 18fc R_OR1K_GOTOFF_AHI16 .rodata.str1.1+0x0011 1908 R_OR1K_GOTOFF_LO16 .rodata.str1.1+0x0011 190c R_OR1K_PLT26 errprintf_nomem 1954 R_OR1K_GOT16 art_blend_sq_diff_8 19ac R_OR1K_GOT_AHI16 art_blend_soft_light_8 19b0 R_OR1K_GOT_AHI16 art_blend_sq_diff_8 19d4 R_OR1K_GOT16 art_blend_soft_light_8 [...] One solution could be pre-scanning the presence of R_OR1K_GOT_AHI16, like in the attached patch (tested, and it works). -- You are receiving this mail because: You are on the CC list for the bug.
