[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 --- Comment #2 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a5a863b4b9cff4bb754fdf602b4aa1c57e73603e commit a5a863b4b9cff4bb754fdf602b4aa1c57e73603e Author: Georg-Johann Lay Date: Fri Dec 15 09:19:08 2023 +0100 Addendum to PR31124 This is a small addendum to PR31124 "rodata in flash for more AVR devices". It adds some symbols so the startup code can set a lock on the FLMAP bit field as specified by the user. New symbols are introduced because otherwise, all the computations / decisions would have to be performed at run-time. It approved, please apply to master. Johann -- ld/ PR 31124 * scripttempl/avr.sc: Adjust comments. [MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock. Remove __flmap_lsl4. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31162] Memory Leak in ldwrite.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31162 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2023-12-15 Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Georg-Johann Lay --- Closed as completed. See also https://gcc.gnu.org/PR112944 Below is a snip from the new comments in ./ld/scripttempl/avr.sc: ___ HAVE_FLMAP == The .rodata section is located in program memory. Devices from the AVR64* and AVR128* families (from avrxmega2 and avrxmega4) see a 32k segment of their program memory in their RAM address space. Which 32k segment is visible is determined by the bit-field NVMCTRL_CTRLB.FLMAP. Output section .rodata is placed in MEMORY region rodata. The LMA of the .rodata section can be set by means of: __RODATA_FLASH_START__ specifies the byte address of the rodata LMA. __flmap specifies which 32k block is visible in RAM provided __RODATA_FLASH_START__ is undefined When __flmap and __RODATA_FLASH_START__ are undefined, then an emulation-specific default is used (the last 32k block). MAYBE_FLMAP === For devices from avrxmega2 and avrxmega4: The user can chose whether or not .rodata is located in flash (if HAVE_FLMAP) or located in in RAM (if not HAVE_FLMAP by means of -mrodata-in-ram). This is achieved by new emulations avrxmega2_flmap and avrxmega4_flmap that are selected by compiler option -mno-rodata-in-ram. In order to facilitate initialization of NVMCTRL_CTRLB.FLMAP and NVMCTRL_CTRLB.FLMAPLOCK in the startup code irrespective of HAVE_FLMAP, the following symbols are used / defined in order to communicate with the startup code. Notice that the hardware default for FLMAP is the last 32k block, so that explicit initialization of FLMAP is only required when the user wants to deviate from the defaults. __flmap = HAVE_FLMAP ? given by __flmap resp. __RODATA_FLASH_START__ >> 15 : 0; __flmap_value = __flmap << __flmap_bpos; __flmap_value_with_lock = __flmap__value | __flmap_lock_mask; __flmap_init_label = HAVE_FLMAP ? __flmap_init_start : __flmap_noinit_start; Supposed to be used as a jump target for RJMP so that the code can initialize FLMAP / skip initialization of FLMAP depending on the chosen emulation, and without the need to support two code versions of crt.o for the two possible emulations. __flmap_lock is a bool provided by the user when FLMAP should be protected from any further changes. __flmap_lock_mask is an 8-bit mask like NVMCTRL_FLMAPLOCK_bm provided by the user which is set in __flmap_value_with_lock when __flmap_lock is on. __do_init_flmap = HAVE_FLMAP ? 1 : 0; Whether or not FLMAP is supposed to be initialized according to, and for the purpose of, .rodata in flash. Apart from that, the compiler (device-specs actually) defines the following macros: __AVR_HAVE_FLMAP__ Defined if a device has the NVMCTRL_CTRLB.FLMAP bitfield *AND* if it's unknown at compile-time / assembler-time whether emulation avrxmega* is used or avrxmega*_flmap. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 Georg-Johann Lay changed: What|Removed |Added URL||https://gcc.gnu.org/PR11294 ||4 -- You are receiving this mail because: You are on the CC list for the bug.
Issue 64089 in oss-fuzz: binutils:fuzz_objdump_safe: Null-dereference READ in read_and_display_attr_value
Updates: Labels: -restrict-view-commit Comment #3 on issue 64089 by sheriffbot: binutils:fuzz_objdump_safe: Null-dereference READ in read_and_display_attr_value https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64089#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/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |2.42 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31148] Segmentation fault in bfd/elf32-hppa.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31148 --- Comment #1 from Sourceware Commits --- The master branch has been updated by John David Anglin : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fc4ddd6734e522debe7e99812b743b368f1cc946 commit fc4ddd6734e522debe7e99812b743b368f1cc946 Author: John David Anglin Date: Fri Dec 15 21:02:32 2023 + Fix segmentation fault in bfd/elf32-hppa.c 2023-12-15 John David Anglin PR ld/31148 bfd/ChangeLog: * elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output relative reloc only when eh->root.type is bfd_link_hash_defined or bfd_link_hash_defweak. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31148] Segmentation fault in bfd/elf32-hppa.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31148 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Fixed on master. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31171] New: ld generates gratuitous PLT entries on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=31171
Bug ID: 31171
Summary: ld generates gratuitous PLT entries on ARM
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
This looks like it may be the same as
https://sourceware.org/bugzilla/show_bug.cgi?id=22374 for other archs. I was
testing with the program:
#include
static void (*f)() = abort;
int main() {
return (long)f;
}
built with -O0 so there's no attempt at determining that f doesn't change and
inlining it. The emitted asm and .o file clearly do not contain any references
to abort from .text; however, the linked executable has JUMP_SLOT relocations
and abort@plt instructions.
Both 32-bit arm and aarch64 are affected.
The condition for generating a PLT entry (and analogously, for data, a copy
relocation) should be that the symbol is referenced from text, not that it's a
function-type symbol being referenced at all. References from data do not need
PLT entries or copy relocations.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31171] ld generates gratuitous PLT entries on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=31171 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=22374 CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22374] Unnecessary PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=22374 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22374] Unnecessary PLT entries
https://sourceware.org/bugzilla/show_bug.cgi?id=22374 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31171 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31148] Segmentation fault in bfd/elf32-hppa.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31148 Sam James changed: What|Removed |Added CC||sam at gentoo dot org Target Milestone|--- |2.42 -- You are receiving this mail because: You are on the CC list for the bug.
PE header copyright issue
I started looking into EFI64 development for reasons, and discovered
something totally unexpected. The Debian grub64 loader and shim both
start with some ancient MS-owned code, and the code is obviously the
same stupid MS owned code that MS uses in their build tools since
forever, and we can tell this because of an ancient bad bit of code
writing in it. I researched the provenance of the 16 bit code and
found what I expected; it was blindly imported by the original
development of binutils-pe32 output target by looking at the output of
the MS linker without understanding it.
I re-developed the stub 16 bit code, and prepared a patch to replace
the MS own code with my own.
I tested this by placing it after the 64 byte header lifted from
debian grub EFI, resulting in a 117 byte binary (trailing zeros were
eaten by the build pathway), and ran it in Dosbox to verify the error
message appears as expected.
Patch signed off by Joshua Hudson
$ gpg --clearsign --not-dash-escaped < binutilspe16.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
NotDashEscaped: You need gpg to verify this message
diff --git a/bfd/peicode.h b/bfd/peicode.h
index e16bfc25437..3d253a45f4f 100644
--- a/bfd/peicode.h
+++ b/bfd/peicode.h
@@ -258,16 +258,13 @@ coff_swap_scnhdr_in (bfd * abfd, void * ext, void * in)
static bool
pe_mkobject (bfd * abfd)
{
- /* Some x86 code followed by an ascii string. */
+ /* DOS error message emitter followed by message */
static const char default_dos_message[64] = {
-0x0e, 0x1f, 0xba, 0x0e, 0x00, 0xb4, 0x09, 0xcd,
-0x21, 0xb8, 0x01, 0x4c, 0xcd, 0x21, 0x54, 0x68,
-0x69, 0x73, 0x20, 0x70, 0x72, 0x6f, 0x67, 0x72,
-0x61, 0x6d, 0x20, 0x63, 0x61, 0x6e, 0x6e, 0x6f,
-0x74, 0x20, 0x62, 0x65, 0x20, 0x72, 0x75, 0x6e,
-0x20, 0x69, 0x6e, 0x20, 0x44, 0x4f, 0x53, 0x20,
-0x6d, 0x6f, 0x64, 0x65, 0x2e, 0x0d, 0x0d, 0x0a,
-0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
+0xba, 0x0c, 0x01, 0xb4, 0x09, 0xcd, 0x21, 0xb8,
+0x01, 0x4c, 0xcd, 0x21, "This",
+" program cannot ",
+"be run in DOS mo",
+"de.\x0d\x0a$" };
pe_data_type *pe = bfd_zalloc (abfd, sizeof (*pe));
abfd->tdata.pe_obj_data = pe;
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEzQMuEig2Xhk0+cu7b7uWgHSsbDwFAmV8614ACgkQb7uWgHSs
bDxlPgf/WNlQsCN+lVpaq74FYgC2qGk2HTAywNHurlKWaEgguSmiMCWK/Ma9osyw
NJ3O7W09UN1YVHt35LC6THItvK+R0gmXNRUd6gmOQh98c4mYLW958ctN8X2ILhND
80OnOMGe6ERloJAOlP/WstiqGk6Isz0Wh3gvQNFkkH9VglJVSjqgIW9aj+vKoGY4
sbfuuiYae/hpKdY1G9vGAVgmAJK1uW3CJmx55rwDq7QSTde2kfzLoWaufu96QBUR
PR0YyodAoa5CSPgQPs+Wud/lQ/1qJo4IwGisyN7Zgt9uVGF41pYK+DGiSgfHZnsM
r/X/XWUeT2TeNtVSUEqUyrcDtq7lNg==
=AXHa
-END PGP SIGNATURE-
[Bug ld/27442] FAIL: Local ifunc-using executable does not contain R_*_IRELATIVE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=27442 Sam James changed: What|Removed |Added Target Milestone|--- |2.38 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31043] Poor error message for wrong register numbers
https://sourceware.org/bugzilla/show_bug.cgi?id=31043 Sam James changed: What|Removed |Added Target Milestone|--- |2.42 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Sam James --- Shall we call this one done for 2.42? It makes the error message for the reported case better and I don't have any other issues. -- 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 #5 from Sam James --- Any update here? It'd be great to have this one fixed before 2.42. -- You are receiving this mail because: You are on the CC list for the bug.
