[Bug gold/29462] internal error in relocate, at powerpc.cc:10796
https://sourceware.org/bugzilla/show_bug.cgi?id=29462 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6158b25f77db11712b84e6a4609898f2615ac749 commit 6158b25f77db11712b84e6a4609898f2615ac749 Author: Alan Modra Date: Wed Aug 10 10:38:52 2022 +0930 PR29462, internal error in relocate, at powerpc.cc:10796 Prior to the inline plt call support (commit 08be322439), the only local syms with plt entries were local ifunc symbols. There shouldn't be stubs for other local symbols so don't look for them. The patch also fixes minor bugs in get_reference_flags; Many relocs are valid only for ppc64 and a couple only for ppc32. PR 29462 * powerpc.cc (Target_powerpc::Relocate::relocate): Rename use_plt_offset to pltcal_to_direct, invert logic. For relocs not used with inline plt sequences against local symbols, only look for stubs when the symbol is an ifunc. (Target_powerpc::Scan::get_reference_flags): Correct reloc handling for relocs not valid for both 32-bit and 64-bit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29462] internal error in relocate, at powerpc.cc:10796
https://sourceware.org/bugzilla/show_bug.cgi?id=29462 Alan Modra changed: What|Removed |Added Last reconfirmed||2022-08-10 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|ccoutant at gmail dot com |amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
Re: A request to add information on gprofng
On 8/9/22 2:44 PM, Ruud van der Pas wrote: Hi Nick, Thanks again for the help with this. We came up with the following one liner for the list. I've used the same HTML format as used for the other entries: gprofng - Collects and displays application performance data. also we might want to change the one liner on https://sourceware.org/binutils/ to match the new one above. thank you Kurt Related to this, we were wondering if we can get a gprofng page on https://sourceware.org/projects.html We would like to provide practical information to the users, along the lines of what the glibc folks are doing: https://www.gnu.org/software/libc/libc.html Kind regards, Ruud On 9 Aug 2022, at 16:43, Nick Clifton wrote: Hi Ruud, Since we are now part of the GNU binutils 2.39 release, I wonder if gprofng can be added to the list on the main binutils web site: Doh! Sorry - this is my bad. I should have thought to ask you. https://www.gnu.org/software/binutils/ If this is possible, please advise how to proceed. Take a slice of lemon, wrap it around a gold brick and, oh no, sorry, that is the recipe for a pan galactic gargle blaster. Ahem. If you can tell me what you want to say I will add it to the page. Even better if you can provide me with some HTML formatted text I can just insert it at the proper place. Cheers Nick
[Bug gprofng/29465] [display html] File version.texi is created in the binutils source directory
https://sourceware.org/bugzilla/show_bug.cgi?id=29465 Ruud van der Pas changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29465] [display html] File version.texi is created in the binutils source directory
https://sourceware.org/bugzilla/show_bug.cgi?id=29465 Ruud van der Pas changed: What|Removed |Added Assignee|unassigned at sourceware dot org |ruud.vanderpas at oracle dot com Component|binutils|gprofng Version|2.39|2.40 (HEAD) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29465] New: [display html] File version.texi is created in the binutils source directory
https://sourceware.org/bugzilla/show_bug.cgi?id=29465 Bug ID: 29465 Summary: [display html] File version.texi is created in the binutils source directory Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- File version.texi is part of the gprofng user guide. It is created in the source directory. This is not good, because the source directory should be kept clean, and may also be read-only. This file should be in the build directory instead. -- You are receiving this mail because: You are on the CC list for the bug.
Re: A request to add information on gprofng
Hi Nick, Thanks again for the help with this. We came up with the following one liner for the list. I've used the same HTML format as used for the other entries: gprofng - Collects and displays application performance data. Related to this, we were wondering if we can get a gprofng page on https://sourceware.org/projects.html We would like to provide practical information to the users, along the lines of what the glibc folks are doing: https://www.gnu.org/software/libc/libc.html Kind regards, Ruud > On 9 Aug 2022, at 16:43, Nick Clifton wrote: > > Hi Ruud, > >> Since we are now part of the GNU binutils 2.39 release, I wonder >> if gprofng can be added to the list on the main binutils web site: > > Doh! Sorry - this is my bad. I should have thought to ask you. > >> https://www.gnu.org/software/binutils/ >> If this is possible, please advise how to proceed. > > Take a slice of lemon, wrap it around a gold brick and, oh no, sorry, > that is the recipe for a pan galactic gargle blaster. Ahem. > > If you can tell me what you want to say I will add it to the page. > Even better if you can provide me with some HTML formatted text I > can just insert it at the proper place. > > Cheers > Nick > > >
Issue 47389 in oss-fuzz: binutils:fuzz_objdump: Out-of-memory in fuzz_objdump
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 47389 by sheriffbot: binutils:fuzz_objdump: Out-of-memory in fuzz_objdump https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47389#c3 This bug has exceeded our disclosure deadline. 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 47401 in oss-fuzz: binutils:fuzz_windres: Null-dereference READ in ubsan_GetStackTrace
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 47401 by sheriffbot: binutils:fuzz_windres: Null-dereference READ in ubsan_GetStackTrace https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47401#c3 This bug has exceeded our disclosure deadline. 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 binutils/29457] Consider making --disassembler-color=color default if terminal
https://sourceware.org/bugzilla/show_bug.cgi?id=29457 Martin Liska changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liska --- Thanks for the implementation. -- You are receiving this mail because: You are on the CC list for the bug.
Re: A request to add information on gprofng
Hi Nick, > Oh yes - I will be there. :-) That is great! It will be really nice to meet in person and I look forward to that :-) Kind regards, Ruud
Re: A request to add information on gprofng
Hi Ruud, By the way, will you be at Cauldron? I plan to attend and would love to meet in person! Oh yes - I will be there. :-) Cheers Nick
Re: A request to add information on gprofng
Hi Nick, Thank you very much for the fast response! I hope you've enjoyed your vacation. > Doh! Sorry - this is my bad. I should have thought to ask you. Hey, no problem at all! Also, you have been really busy getting 2.39 out of the door!! > Take a slice of lemon, wrap it around a gold brick and, oh no, sorry, > that is the recipe for a pan galactic gargle blaster. Ahem. LOL > If you can tell me what you want to say I will add it to the page. > Even better if you can provide me with some HTML formatted text I > can just insert it at the proper place. That is great! Thanks very much :-) We'll have our gprofng meeting in a little over 2 hours and I will bring it up. I'll send you the text soon after. By the way, will you be at Cauldron? I plan to attend and would love to meet in person! Kind regards, Ruud
Re: A request to add information on gprofng
Hi Ruud, Since we are now part of the GNU binutils 2.39 release, I wonder if gprofng can be added to the list on the main binutils web site: Doh! Sorry - this is my bad. I should have thought to ask you. https://www.gnu.org/software/binutils/ If this is possible, please advise how to proceed. Take a slice of lemon, wrap it around a gold brick and, oh no, sorry, that is the recipe for a pan galactic gargle blaster. Ahem. If you can tell me what you want to say I will add it to the page. Even better if you can provide me with some HTML formatted text I can just insert it at the proper place. Cheers Nick
A request to add information on gprofng
Hello! My name is Ruud van der Pas and I am one of the people involved with the development of gprofng, the new GNU profiling tool. Since we are now part of the GNU binutils 2.39 release, I wonder if gprofng can be added to the list on the main binutils web site: https://www.gnu.org/software/binutils/ If this is possible, please advise how to proceed. Thank you very much in advance for the help! Kind regards, Ruud
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
https://sourceware.org/bugzilla/show_bug.cgi?id=29457 --- Comment #3 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=a88c79b77036e4778e70d62081c3cfd1044bb8e3 commit a88c79b77036e4778e70d62081c3cfd1044bb8e3 Author: Nick Clifton Date: Tue Aug 9 14:57:48 2022 +0100 Default to enabling colored disassembly if output is to a terminal. PR 29457 * objdump.c (disassembler_color): Change type to an enum. (disassembler_extended_color): Remove. (usage): Update. (objdump_color_for_assembler_style): Update. (main): Update initialisation of disassembler_color. If not initialised via a command line option, set based upon terminal output. * doc/binutils.texi: Update description of disassmbler-color option. * testsuite/binutils-all/arc/objdump.exp: Add --disassembler-color=off option when disassembling. * testsuite/binutils-all/arm/objdump.exp: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451 --- Comment #13 from Jan Beulich --- See patch at https://sourceware.org/pipermail/binutils/2022-August/122322.html. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451 --- Comment #12 from Jan Beulich --- Yeah, I can certainly see my thinko. Making a patch ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451 --- Comment #11 from Mark Wielaard --- (In reply to Jan Beulich from comment #8) > (In reply to Mark Wielaard from comment #7) > > > and the symbol size is also 0 in the table: > > > $ readelf -s crti.o > > > > > > Symbol table '.symtab' contains 11 entries: > > >Num:Value Size TypeBind Vis Ndx Name > > > ... > > > 9: 0 FUNCGLOBAL HIDDEN 5 _init > > > > So if the size really is zero than high_pc should be one larger than low_pc > > (if expressed as addr in DWARF < 4) and 1 if expressed as unsigned constant > > (for DWARF >=4) > > > > Having the addresses equal or high_pc zero does not express the zero sized > > region. > > Doesn't high_pc being one larger than low_pc express a 1-byte region? Yes, you are right. Technically since high_pc is one past the last address it describes just a single address (of low_pc). To describe a DIE without size you should only emit a low_pc attribute and no high_pc attribute. According to the DWARF spec a DIE that has a machine code address or range of machine code addresses associated has: • A DW_AT_low_pc attribute for a single address, • A DW_AT_low_pc and DW_AT_high_pc pair of attributes for a single contiguous range of addresses, or • A DW_AT_ranges attribute for a non-contiguous range of addresses. Where the high_pc expresses the first location past the last instruction associated with the entity. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29457] Consider making --disassembler-color=color default if terminal
https://sourceware.org/bugzilla/show_bug.cgi?id=29457 --- Comment #2 from Martin Liska --- Yes, thanks for it. I've just tested the patch and it looks nice! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #10 from Martin Liska ---
(In reply to Jan Beulich from comment #9)
> The commit in question actually tries to avoid emitting zero-sized regions,
> so the question is why
>
> if (S_GET_SIZE (symp) == 0)
> {
> if (!IS_ELF || symbol_get_obj (symp)->size == NULL)
> continue;
> }
>From the debugging session, I can confirm the continue branch is taken for:
(gdb) p *symp
$2 = {
flags = {
local_symbol = 0,
written = 0,
resolved = 0,
resolving = 0,
used_in_reloc = 0,
used = 0,
volatil = 0,
forward_ref = 0,
forward_resolved = 0,
mri_common = 0,
weakrefr = 0,
weakrefd = 0,
removed = 0,
multibyte_warned = 0
},
hash = 3929827014,
name = 0x609c50 "_init",
frag = 0x60b6f8,
bsym = 0x5daed8,
x = 0x609c88
}
(gdb) p symbol_get_obj (symp)->size
$3 = (expressionS *) 0x0
>
> doesn't have the intended effect in the case at hand. With no .size
> directive I don't see why / how ->size could be non-NULL.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451
--- Comment #9 from Jan Beulich ---
The commit in question actually tries to avoid emitting zero-sized regions, so
the question is why
if (S_GET_SIZE (symp) == 0)
{
if (!IS_ELF || symbol_get_obj (symp)->size == NULL)
continue;
}
doesn't have the intended effect in the case at hand. With no .size directive I
don't see why / how ->size could be non-NULL.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size
https://sourceware.org/bugzilla/show_bug.cgi?id=29451 --- Comment #8 from Jan Beulich --- (In reply to Mark Wielaard from comment #7) > > and the symbol size is also 0 in the table: > > $ readelf -s crti.o > > > > Symbol table '.symtab' contains 11 entries: > >Num:Value Size TypeBind Vis Ndx Name > > ... > > 9: 0 FUNCGLOBAL HIDDEN 5 _init > > So if the size really is zero than high_pc should be one larger than low_pc > (if expressed as addr in DWARF < 4) and 1 if expressed as unsigned constant > (for DWARF >=4) > > Having the addresses equal or high_pc zero does not express the zero sized > region. Doesn't high_pc being one larger than low_pc express a 1-byte region? -- You are receiving this mail because: You are on the CC list for the bug.
