[Bug gprofng/30889] can't compile without large file support
https://sourceware.org/bugzilla/show_bug.cgi?id=30889 Vladimir Mezentsev changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host
https://sourceware.org/bugzilla/show_bug.cgi?id=29593 --- Comment #4 from Vladimir Mezentsev --- Has the build problem been fixed in your environment? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)
https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #9 from Vladimir Mezentsev --- Has the build problem been fixed in your environment? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31123] improvements to hardware event implementation
https://sourceware.org/bugzilla/show_bug.cgi?id=31123 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31123] improvements to hardware event implementation
https://sourceware.org/bugzilla/show_bug.cgi?id=31123 --- Comment #1 from Sourceware Commits --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8fe04eeb2cbb8c4cf7b6e8d9183fe09a8b2e8d51 commit 8fe04eeb2cbb8c4cf7b6e8d9183fe09a8b2e8d51 Author: Vladimir Mezentsev Date: Mon Jan 8 22:00:24 2024 -0800 gprofng: 31123 improvements to hardware event implementation Our hardware counter profiling is based on perf_event_open(). Our HWC tables are absent for new machines. I have added HWC tables for the following events: PERF_TYPE_HARDWARE, PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. Did a little cleaning: marked the symbols as static, used Stringbuilder, created a function to read /proc/cpuinfo. gprofng/ChangeLog 2024-01-08 Vladimir Mezentsev PR gprofng/31123 * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. * common/hwc_cpus.h: Declare a new function read_cpuinfo. * common/hwcdrv.c: Add a new parameter in init_perf_event(). * common/hwcentry.h: Add use_perf_event_type in Hwcentry. * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, type, config. * common/hwctable.c: Add a new HWC table generic_list[]. * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). Add a new function read_cpuinfo. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 --- Comment #17 from Nick Clifton --- (In reply to Pete Moore from comment #16) > If a 2.41.1 release is undesirable, another option could be to add a comment > to the release notes of 2.41 to specify that makeinfo version 6.8 or higher > is required, or set MAKEINFO=true. > > Is it acceptable to update release notes, post release? By release notes, I assume that you mean the binutils/README file ? Then sure - adding a comment there on the 2.41 branch is certainly reasonable. But this will only be of help to people who download the sources from the branch. Another possibility is to add a description of the problem - and its workaround - to the binutils web page: https://sourceware.org/binutils/ As it happens there is already a precedent for this, as there was another problem with the 2.41 release which needed to be documented on the web page. It may also be of interest to know that the 2.42 release is due out at the end of this month (Jan '24 for those reading these comments after the fact), and all being well, that release will not have this problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31228] ld (aarch64): undefined reference to `no symbol' for adrp with constant value
https://sourceware.org/bugzilla/show_bug.cgi?id=31228 --- Comment #2 from Pete Moore --- Many thanks Nick for quick response! Sorry for not testing on 2.41 before, I should have done that. On that note, I just went to test this on 2.41 and hit the issue described in bug 30703 comment 16... Thanks, Pete -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 Pete Moore changed: What|Removed |Added CC||petemoore at gmx dot net --- Comment #16 from Pete Moore --- I just got burned by this, after attempting to build 2.41 from https://ftp.gnu.org/gnu/binutils/binutils-2.41.tar.gz I think if there had been a 2.41.1 release, I would have picked that and not had the issue. If a 2.41.1 release is undesirable, another option could be to add a comment to the release notes of 2.41 to specify that makeinfo version 6.8 or higher is required, or set MAKEINFO=true. Is it acceptable to update release notes, post release? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Nick Clifton --- The bug is fixed in the 2.41 release. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31228] ld (aarch64): undefined reference to `no symbol' for adrp with constant value
https://sourceware.org/bugzilla/show_bug.cgi?id=31228 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Nick Clifton --- Hi Pete, This bug is fixed in the 2.41 release: $ as adrp.s -o adrp.o $ ld -Ttext=0 adrp.o Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31228] New: ld (aarch64): undefined reference to `no symbol' for adrp with constant value
https://sourceware.org/bugzilla/show_bug.cgi?id=31228 Bug ID: 31228 Summary: ld (aarch64): undefined reference to `no symbol' for adrp with constant value Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: petemoore at gmx dot net Target Milestone: --- Consider the following assembly: ``` $ cat adrp.s .global _start _start: adrp x0, 0x8000 ``` After assembling and linking: ``` $ aarch64-none-elf-as -o adrp.o adrp.s $ aarch64-none-elf-ld -Ttext=0x0 -o adrp.elf adrp.o aarch64-none-elf-ld: adrp.o: in function `_start': (.text+0x0): undefined reference to `no symbol' ``` Note, the following trick works (if e.g. _start is known to be 0): ``` $ cat adrp.s .global _start _start: adrp x0, 0x8000 + _start ``` which assembles as desired: ``` $ aarch64-none-elf-objdump -d adrp.elf adrp.elf: file format elf64-littleaarch64 Disassembly of section .text: <_start>: 0: 9040adrpx0, 8000 <_start+0x8000> ``` However, this only works if _start is fixed and known. Being able to specify an absolute (rather than relative) value for the immediate of the adrp instruction is useful for e.g. referencing peripherals at fixed locations which are known to be in the +/- 4GB range of the current address. My particular use case is referencing Raspberry Pi peripheral base addresses when the MMU is not enabled. Originally reported in bug 27217 comment 30. ``` $ aarch64-none-elf-ld --version GNU ld (GNU Binutils) 2.39 ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31213] gas: add diagnostic when skipping CFI directives for SFrame generation
https://sourceware.org/bugzilla/show_bug.cgi?id=31213 Indu Bhagat changed: What|Removed |Added Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
