[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 Fangrui Song changed: What|Removed |Added Assignee|unassigned at sourceware dot org |i at maskray dot me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Implemented in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f5a3546126b47fd3b7a5fbc4ec5fad1397b726b (readelf: support zstd compressed debug sections [PR 29640]) -- 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 #9 from Nick Clifton --- Created attachment 14410 --> https://sourceware.org/bugzilla/attachment.cgi?id=14410=edit Proposed patch Hi Jan, Well I am still not a fan of environment variables, so how about this patch ? It adds a new configure time option --enable-colored-disassembly which defaults to "off'. It also cleans up the arguments to the --disassembler-color= option so that there are now four alternatives: off, on, terminal and extended. (Plus aliases of these options to match the old values). Any suggestions/improvements ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nick Clifton --- Hi Fangrui, > `config.fatal_warnings = false;` makes me wonder how -w interacts with > --fatal-warnings. It seems that -w --fatal-warnings and --fatal-warnings -w > have the same effect (-w wins, which makes sense IMO), so I guess > `config.fatal_warnings = false;` can be omitted. It could, but I feel that it helps to emphasize that -w takes precedence over --fatal-warnings, so I have left it in. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 --- 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=4b2e7a577c2f7311a8c381ff791d46e654c41fcc commit 4b2e7a577c2f7311a8c381ff791d46e654c41fcc Author: Nick Clifton Date: Fri Oct 21 12:20:09 2022 +0100 Add a -w option to the linker to suppress warning and error messages. PR 29654 * ld.h (struct ld_config_type): Add no_warnings field. * ldlex.h (enum option_values): Add OPTION_NO_WARNINGS. * lexsup.c (ld_options): Add --no-warnings. (parse_args): Add support for -w and --no-warnings. * ldmisc.c (vfinfo): Return early if the message is a warning and -w has been enabled. * ld.texi (options): Document new command line option. * NEWS: Mention the new feature. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29707] binutils c++filt reads a file with the first character \x00, it will wait for input and cause the program to block.
https://sourceware.org/bugzilla/show_bug.cgi?id=29707 --- Comment #2 from 烽征战 --- Thanks for your patience! nickc at redhat dot com 于2022年10月21日周五 18:35写道： > https://sourceware.org/bugzilla/show_bug.cgi?id=29707 > > Nick Clifton changed: > >What|Removed |Added > > > Resolution|--- |NOTABUG > Status|UNCONFIRMED |RESOLVED > CC||nickc at redhat dot com > > --- Comment #1 from Nick Clifton --- > Hi, > > This is not a bug, it is expected behaviour. > > c++filt has two modes of operation. If it is given strings on its > command > line then it decodes them one at a time and then exits. If it is not > given any strings to decode then it reads from the standard input stream > and decodes each line until it sees an end-of-file marker. > > Command line options do not count as strings to decode, so running > "c++filt --types" for example will still cause the program to read from > the standard input. In addition c++file supports the @-file syntax, > allowing command line options and strings to decode to be placed into a > file and then passed to c++filt via a command line option of > @. > > So in your test case, running: "c++filt @c++filt/crash01_timeout" causes > the contents of c++filt/crash01_timeout to be read and processed. Since > the file is expected to contain text, not binary, any nul character > (\x00) > is treated as an end-of-file marker, and processing will stop at that > character. > > Hence when the first character of c++filt/crash01_timeout is a nul > character > the entire file is treated as if it were empty, and the logic in c++filt > sees that no strings were provided on the command line, and hence it > starts > to read from stdin, waiting for the user to provide input to decode. > > When the first character of c++filt/crash01_timeout is not a nul > character > the file is treated as having some contents which are passed back to > c++filt > to decode, and so once that is done c++filt terminates. > > Cheers > Nick > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29707] binutils c++filt reads a file with the first character \x00, it will wait for input and cause the program to block.
https://sourceware.org/bugzilla/show_bug.cgi?id=29707 Nick Clifton changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi, This is not a bug, it is expected behaviour. c++filt has two modes of operation. If it is given strings on its command line then it decodes them one at a time and then exits. If it is not given any strings to decode then it reads from the standard input stream and decodes each line until it sees an end-of-file marker. Command line options do not count as strings to decode, so running "c++filt --types" for example will still cause the program to read from the standard input. In addition c++file supports the @-file syntax, allowing command line options and strings to decode to be placed into a file and then passed to c++filt via a command line option of @. So in your test case, running: "c++filt @c++filt/crash01_timeout" causes the contents of c++filt/crash01_timeout to be read and processed. Since the file is expected to contain text, not binary, any nul character (\x00) is treated as an end-of-file marker, and processing will stop at that character. Hence when the first character of c++filt/crash01_timeout is a nul character the entire file is treated as if it were empty, and the logic in c++filt sees that no strings were provided on the command line, and hence it starts to read from stdin, waiting for the user to provide input to decode. When the first character of c++filt/crash01_timeout is not a nul character the file is treated as having some contents which are passed back to c++filt to decode, and so once that is done c++filt terminates. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
