[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #6 from Tom Kacvinsky --- I found an issue with the patch. I applied against master and built it. I then used gcc 12.1.0 and got this: $ /opt/gcc-12.1.0/bin/gcc -B /opt/binutils-2.40-version/bin -fuse-ld=bfd -o wchar wchar.c /opt/binutils-2.40-version/bin/ld.bfd: wchar: error: PHDR segment not covered by LOAD segment If I dump the default linker script and remove the linker version comment option, and use the resulting file as the link scriot: $ /opt/gcc-12.1.0/bin/gcc -B /opt/binutils-2.40-version/bin -fuse-ld=bfd -Wl,--script=noversion.script -o wchar wchar.c this problem goes away. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #5 from Tom Kacvinsky --- (In reply to Nick Clifton from comment #4) > (In reply to Nick Clifton from comment #3) > > > What do you think of the this patch ? > > I have discovered a flaw in the patch. :-( > > Since the version string is now present in the .comment section, that > section is always output, even if there are no input files containing > .comment sections. This breaks many of the linker's own tests and > represents unexpected new behaviour of the linker. *sigh* I will have to > rethink my solution. I'd be OK with a new option. That way, old tests can be such that the new option is not used, the .comment section is not emitted, and things are as they were. Then, write a new test (or tests) that exercise the new option. I see there is often a lot of back and forth on the binutils list about what options should be named, but just as a first stabd, I'd call it "--emit-comment-section" -- You are receiving this mail because: You are on the CC list for the bug.
Issue 56545 in oss-fuzz: binutils:fuzz_objcopy: Out-of-memory in fuzz_objcopy
Updates: Labels: -restrict-view-commit Comment #2 on issue 56545 by sheriffbot: binutils:fuzz_objcopy: Out-of-memory in fuzz_objcopy https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56545#c2 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/30193] ASCII command length checking corner cases not properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=30193 Pekka Seppänen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Pekka Seppänen --- (In reply to Nick Clifton from comment #1) > (In reply to Pekka Seppänen from comment #0) > Hi Pekka, > > > of the input string (that has been processed). As the checking currently > > uses `len >= size' it is not possible to output a string that is exactly the > > allocated size, e.g. `ASCII (5) "ascii"'. > > This is deliberate. The ASCII directive always produces a zero-terminated > string. From the documentation: > > If the string is too long, a warning is issued > and the string is truncated. The string will > still be zero-terminated in this case. > I see, my bad, I was perhaps thinking this being more equal to assembler .ascii and .asciz. Of these two only the latter produces zero-terminated string. It would have been nice to replace 64-bit hex values (that translate to non-terminated ascii strings) with ASCII (8) "" where the value is exactly 8 bytes. > > > Also, as lang_add_string() processes both ASCIZ and ASCII commands it is not > > possible to produce an empty output, e.g. `ASCII (0) ""'. This might be > > useful if the command would be used to produce variable padding. > > I find that very unlikely. Why would the padding need to be in the form of > ascii characters ? > This is obviously personal preference, but I usually like to leave my handmark, or subtle signature, on the software I'm working on. So, many times, I might use something that is human readable as padding (or marker, for that matter). Anyway, I see this sparked an improvement nonetheless and I learned about testsuite internals, so I don't consider this a wasted effort. Thanks, -- Pekka -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30089] [display text] Incorrect thread count shown on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30089 Kurt Goebel changed: What|Removed |Added CC||kurt.goebel at oracle dot com Priority|P3 |P2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30193] ASCII command length checking corner cases not properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=30193 --- 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=adbe951fc95943016325af08d677f18e8c177ac1 commit adbe951fc95943016325af08d677f18e8c177ac1 Author: Nick Clifton Date: Fri Mar 3 13:56:36 2023 + Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant. PR 30193 * ldgram.y (ASCII): Fail if the size is not a constant. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30193] ASCII command length checking corner cases not properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=30193
--- Comment #2 from Nick Clifton ---
Hmmm, I have been thinking about this issue a bit more and uncovered another
problem with the ASCII directive. It assumes that the space is a constant.
Consider this:
% cat ascii.t
SECTIONS
{
.data :
{
*(.data)
data_end = . ;
ASCII ( 40 - data_end ) "goodbye world"
}
/DISCARD/ : { *(*) }
}
% ld ../ld/ld-new foo.o -e 0 -T ascii.t
This creates an output file with a gigantic .data section:
% readelf --wide --sections a.out | grep .data
[ 1] .data PROGBITS 001000 2037650 00 WA 0 0 1
because the expression cannot be evaluated at the time that the script is
parsed, so the value field in the etree_type structure is uninitialised.
Fortunately there is an easy fix:
diff --git a/ld/ldgram.y b/ld/ldgram.y
index faffeec94b8..26e56fe1566 100644
--- a/ld/ldgram.y
+++ b/ld/ldgram.y
@@ -672,7 +672,10 @@ statement:
{
/* 'value' is a memory leak, do we care? */
etree_type *value = $3;
- lang_add_string (value->value.value, $5);
+ if (value->type.node_code == INT)
+ lang_add_string (value->value.value, $5);
+ else
+ einfo (_("%X%P:%pS: ASCII expression must be an
integer\n"), NULL);
}
| ASCIZ NAME
{
I am running some regression tests to see if this breaks anything...
--
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 #7 from Ruud van der Pas --- I'm working on the fix for this and will use this opportunity to enhance the gprofng user guide with the contents of the man pages. In this way, users have access to a description of all the options without the need to install gprofng. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30195] [display text] Source code location can not be found
https://sourceware.org/bugzilla/show_bug.cgi?id=30195 Ruud van der Pas changed: What|Removed |Added CC||ruud.vanderpas at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30195] New: [display text] Source code location can not be found
https://sourceware.org/bugzilla/show_bug.cgi?id=30195 Bug ID: 30195 Summary: [display text] Source code location can not be found Product: binutils Version: 2.40 Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- As the log of my session shown below shows, gprofng cannot find the location of a source file, but the code has been compiled with -g. This error has been observed using gcc 11 on Oracle Linux 9. $ uname -r 5.15.0-5.76.5.1.el9uek.aarch64 $ $ gcc --version gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2.1.0.1) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ make gcc -o ../objects/main.o -c -g -O -Wall -Werror=undef -Wstrict-prototypes main.c gcc -o ../objects/manage_data.o -c -g -O -Wall -Werror=undef -Wstrict-prototypes manage_data.c gcc -o ../objects/workload.o -c -g -O -Wall -Werror=undef -Wstrict-prototypes workload.c gcc -o ../objects/mxv.o -c -g -O -Wall -Werror=undef -Wstrict-prototypes mxv.c gcc -o ../bindir/mxv-pthreads ../objects/main.o ../objects/manage_data.o ../objects/workload.o ../objects/mxv.o -lm -lpthread ldd ../bindir/mxv-pthreads linux-vdso.so.1 (0x8a081000) libm.so.6 => /lib64/libm.so.6 (0x89fa3000) libc.so.6 => /lib64/libc.so.6 (0x89df5000) /lib/ld-linux-aarch64.so.1 (0x8a044000) $ cd ../bindir $ gprofng collect app ./mxv-pthreads -m 8000 -n 4000 CPU clock frequency: 2500 Creating experiment directory test.1.er (Process ID: 2101962) ... mxv: error check passed - rows = 8000 columns = 4000 threads = 1 $ gprofng display text -source mxv_core test.1.er Error: Source location not recorded in experiment $ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30194] [collect app] Investigate occurrences of @PC from a shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=30194 Ruud van der Pas changed: What|Removed |Added CC||ruud.vanderpas at oracle dot com Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30194] New: [collect app] Investigate occurrences of @PC from a shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=30194 Bug ID: 30194 Summary: [collect app] Investigate occurrences of @PC from a shared library Product: binutils Version: 2.40 Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: ruud.vanderpas at oracle dot com Target Milestone: --- While gprofng lists @PC for several functions in shared libraries, perf seems to be able to resolve the function name. This was reported by a user who has been using gprofng on Ubuntu. Below are the function views as shown by gprofng and perf. For example, __strncmp_sse42 shows up in the perf output, but gprofng reports this as @0x1711f1 (). It will be good to investigate where this difference comes from and whether gprofng can be improved to resolve the function name(s). This is what gprofng display text shows: Excl. Total Incl. TotalName CPU CPU sec. % sec. % 0.690 100.00 0.690 100.00 0.140 20.29 0.490 71.01 ada::parser::parse_url(std::basic_string_view >, ada::url const*, ada::encoding_type) 0.130 18.84 0.130 18.84 @0x1711f1 () 0.050 7.25 0.510 73.91 ada::parse(std::basic_string_view >, ada::url const*, ada::encoding_type) 0.050 7.25 0.650 94.20 void BasicBench_AdaURL(benchmark::State&) 0.040 5.80 0.040 5.80 ada::unicode::to_lower_ascii(char*, unsigned long) [clone .isra.0] 0.040 5.80 0.040 5.80 malloc 0.030 4.35 0.030 4.35 ioctl 0.030 4.35 0.070 10.14 operator new(unsigned long) 0.030 4.35 0.090 13.04 std::__cxx11::basic_string, std::allocator >::_M_append(char const*, unsigned long) 0.030 4.35 0.030 4.35 std::basic_string_view >::substr(unsigned long, unsigned long) const 0.020 2.90 0.020 2.90 @0x9dcd3 () 0.020 2.90 0.040 5.80 free 0.010 1.45 0.010 1.45 @0x7a30 () 0.010 1.45 0.010 1.45 @0x9e160 () 0.010 1.45 0.010 1.45 ada::checkers::has_hex_prefix(std::basic_string_view >) 0.010 1.45 0.010 1.45 ada::url::~url() 0.010 1.45 0.010 1.45 bool std::all_of(char const*, char const*, bool (*)(char) noexcept) ... This is what perf reports (perf record/perf report): Samples: 28K of event 'cycles:u', Event count (approx.): 23444784147 Overhead CommandShared Object Symbol 29.08% bbc_bench bbc_bench [.] ada::parser::parse_url 10.71% bbc_bench libc.so.6 [.] __strncmp_sse42 9.16% bbc_bench bbc_bench [.] BasicBench_AdaURL 5.69% bbc_bench libc.so.6 [.] wcstold_l_internal 5.55% bbc_bench libc.so.6 [.] __strncasecmp_l_sse42 3.66% bbc_bench bbc_bench [.] ada::parse 3.62% bbc_bench libstdc++.so.6.0.30 [.] std::__cxx11::basic_string, std::allocator >::push_back 3.31% bbc_bench bbc_bench [.] std::basic_string_view >::substr 3.00% bbc_bench libstdc++.so.6.0.30 [.] std::__cxx11::basic_string, std::allocator >::_M_mutate 2.83% bbc_bench bbc_bench [.] ada::unicode::to_lower_ascii 2.79% bbc_bench libc.so.6 [.] wcstod_l_internal 2.64% bbc_bench libstdc++.so.6.0.30 [.] std::__cxx11::basic_string, std::allocator >::_M_append 2.59% bbc_bench bbc_bench [.] std::basic_string_view >::find 2.31% bbc_bench bbc_bench [.] ada::url::~url 2.26% bbc_bench libstdc++.so.6.0.30 [.] std::__cxx11::basic_string, std::allocator >::_M_create 1.05% bbc_bench libstdc++.so.6.0.30 [.] operator new 0.91% bbc_bench bbc_bench [.] standard_url::~standard_url -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187 --- Comment #4 from Nick Clifton --- (In reply to Nick Clifton from comment #3) > What do you think of the this patch ? I have discovered a flaw in the patch. :-( Since the version string is now present in the .comment section, that section is always output, even if there are no input files containing .comment sections. This breaks many of the linker's own tests and represents unexpected new behaviour of the linker. *sigh* I will have to rethink my solution. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30187] ld.bfd and ld.gold versions in .comment section of ELF files
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #3 from Nick Clifton ---
Created attachment 14728
--> https://sourceware.org/bugzilla/attachment.cgi?id=14728&action=edit
Proposed patch
Hi Tom,
What do you think of the this patch ?
It adds a new linker script directive called LINKER_VERSION, which if used
inserts the current linker version identity string at the current location.
Then it enhances the default linker script for (most) ELF based targets so
that this directive is added to the end of the .comment section.
Using a linker script directive means that the string can be placed whever
the user wishes (by creating their own linker scripts) or not at all (again
with a custom script).
Here is an example of it in use:
% gcc -c hello.c
% ld hello.o -e 0 --defsym printf=0
% readelf -p.comment a.out
String dump of section '.comment':
[ 0] GCC: (GNU) 12.0.1 20220413 (Red Hat 12.0.1-0)
[2e] GNU ld (GNU Binutils) 2.40.50.20230303
% ld --verbose | grep comment
.comment 0 : { *(.comment); LINKER_VERSION; }
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30193] ASCII command length checking corner cases not properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=30193 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Pekka Seppänen from comment #0) Hi Pekka, > of the input string (that has been processed). As the checking currently > uses `len >= size' it is not possible to output a string that is exactly the > allocated size, e.g. `ASCII (5) "ascii"'. This is deliberate. The ASCII directive always produces a zero-terminated string. From the documentation: If the string is too long, a warning is issued and the string is truncated. The string will still be zero-terminated in this case. > Also, as lang_add_string() processes both ASCIZ and ASCII commands it is not > possible to produce an empty output, e.g. `ASCII (0) ""'. This might be > useful if the command would be used to produce variable padding. I find that very unlikely. Why would the padding need to be in the form of ascii characters ? Cheers Nick PS, Thank you very much for creating a patch to fix the problem. It is not often that we get a bug report with an accompanying fix. I am sorry if my comments above seem harsh, it is just that I think that in this case, the current behaviour is actually correct. -- You are receiving this mail because: You are on the CC list for the bug.
