[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
https://sourceware.org/bugzilla/show_bug.cgi?id=25202 --- Comment #17 from Nick Clifton --- (Sorry for the delay in replying - I have been distracted by other work). I think that we can avoid the alignment problem by insisting that for widths greater than one, the section(s) being converted must already be aligned and padded to multiples of that width. Hence, please could you try out the third iteration of the patch, which should generate the correct address for widths > 1, and which will refuse to convert unaligned sections. I was not sure what to do about sections which are not padded to the required alignment, so I have left the code in its current form. The code will just stop generating bytes when it reaches the end of the section being converted and it will not generate any padding bytes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
https://sourceware.org/bugzilla/show_bug.cgi?id=25202 Nick Clifton changed: What|Removed |Added Attachment #14438|0 |1 is obsolete|| --- Comment #18 from Nick Clifton --- Created attachment 14470 --> https://sourceware.org/bugzilla/attachment.cgi?id=14470&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 --- Comment #10 from Richard Earnshaw --- (In reply to Szabolcs Nagy from comment #9) > i ran into this again and i think the linker could relax 'adrp xN, weaksym' > into 'mov xN, 0' if weaksym is undefined. Static linker or dynamic? The dynamic linker can't change any code segment during loading, since that would break the code-sharing model used by SVr4-like systems. I don't see how the static linker can know that a dynamically loaded library won't provide a definition at run-time, so that doesn't make a lot of sense to me either. > > link error is not helpful since such code (accessing weak symbols) may be > behind checks and unreachable if the symbol is undefined. > > normally weak syms are accessed via GOT which can be 0 for undef, but in PIC > this depends on a dynamic relocation even for hidden visibility syms. this > does not work in early start code (e.g. *crt1.o) accessing weak, linker > generated symbols (such as __ehdr_start) where the code must not generate > dynamic relocations (since it may be executed before ld.so or static pie > self relocation). if such symbol is potentially undefined then we have a > problem: adrp does not work, GOT does not work, movz does not work. so i > dont see a way to implement > > if (&weaksym != 0) > use(&weaksym); > > logic in the ld.so or static pie start code. i ran into this with the > morello port where there are linker created symbols (__rela_dyn_start) that > are only defined under certain conditions (static exe with no > dynamic-linker) and must be checked and accessed in gcrt1.o that is used in > both pde and pie. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Clifton --- Hi Christophe, What do you think of the uploaded patch ? It alters the tests to use -marm: on the objdump command line, so that the exact architecture is specified as well. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 14471 --> https://sourceware.org/bugzilla/attachment.cgi?id=14471&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 --- Comment #3 from Christophe Lyon --- Hi Nick, It seems your patch does the trick, but I imagined we'd want a more general solution (that is, do we want add such an optional prefix in all targets)? But yeah, the coincidence can probably be considered vendor-specific? (I'm not a maintainer though ;-) ) That being said, doesn't adding such a prefix require updating some piece of documentation? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 --- Comment #11 from Szabolcs Nagy --- (In reply to Richard Earnshaw from comment #10) > (In reply to Szabolcs Nagy from comment #9) > > i ran into this again and i think the linker could relax 'adrp xN, weaksym' > > into 'mov xN, 0' if weaksym is undefined. > > Static linker or dynamic? The dynamic linker can't change any code segment > during loading, since that would break the code-sharing model used by > SVr4-like systems. I don't see how the static linker can know that a > dynamically loaded library won't provide a definition at run-time, so that > doesn't make a lot of sense to me either. for extern weak reference with dynamic linking yes (but such references have to go through indirection anyway that can turn into 0 already), adrp+add like access only makes sense for hidden weak syms or in case of static linking which is known by the static linker. my use case is hidden weak symbol access. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 --- Comment #4 from Nick Clifton --- (In reply to Christophe Lyon from comment #3) Hi Christophe, > It seems your patch does the trick, but I imagined we'd want a more general > solution (that is, do we want add such an optional prefix in all targets)? Oh it is supported for all targets, but only when the default cpu scan() function is used. (See bfd/archures.c:bfd_default_scan). If the architecture provides its own scan function, then this needs to support the : syntax in order for it to work. (The AArch64 and ARM architectures being obvious culprits in this case). > That being said, doesn't adding such a prefix require updating some piece of > documentation? Yes - you are right. We should update the documentation as well. Do you want to update the patch or shall I ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 --- Comment #5 from Christophe Lyon --- (In reply to Nick Clifton from comment #4) > (In reply to Christophe Lyon from comment #3) > > Hi Christophe, > > > It seems your patch does the trick, but I imagined we'd want a more general > > solution (that is, do we want add such an optional prefix in all targets)? > > Oh it is supported for all targets, but only when the default cpu scan() > function is used. (See bfd/archures.c:bfd_default_scan). If the > architecture provides its own scan function, then this needs to support > the : syntax in order for it to work. (The AArch64 and ARM > architectures being obvious culprits in this case). Sorry, I wasn't aware of this feature, so that's a real bug in AArch64 and ARM implementations. > > That being said, doesn't adding such a prefix require updating some piece of > > documentation? > > Yes - you are right. We should update the documentation as well. Do you > want > to update the patch or shall I ? > Please go ahead :-) Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 H.J. Lu changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #10 from H.J. Lu --- Linker removed the local symbol _CRT0_EH_FRAME_BEGIN_ since its section, .eh_frame, was unused and removed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #11 from Stas Sergeev --- (In reply to H.J. Lu from comment #10) > Linker removed the local symbol _CRT0_EH_FRAME_BEGIN_ since its section, > .eh_frame, > was unused and removed. But why it only removed the name of a symbol? Can it remove the symbol properly? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 --- Comment #6 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=1a7e622b82fa621ab505dd911bc30c1efcb4a9b0 commit 1a7e622b82fa621ab505dd911bc30c1efcb4a9b0 Author: Nick Clifton Date: Mon Nov 21 16:44:02 2022 + Fix ARM and AArch64 assembler tests to work in a multi-arch environment. PR 29764 gas * testsuite/gas/arm/cpu-cortex-a76ae.d: Add arm prefix to the -m option passed to objdump. * testsuite/gas/arm/cpu-cortex-a77.d: Likewise. * testsuite/gas/aarch64/cpu-cortex-a76ae.d: Add aarch64 prefix to the -m option passed to objdump. * testsuite/gas/aarch64/cpu-cortex-a77.d: Likewise. bfd * cpu-arm.c (scan): Accept machine names prefixed with "arm:". * cpu-aarch64.c (scan): Accept machine names prefixed with "aarch64:". bin * doc/binutils.texi (objdump): Note that the -m option supports the : syntax. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29764] objdump confused with --enable-targets=all if several machines include the same cpu name
https://sourceware.org/bugzilla/show_bug.cgi?id=29764 --- Comment #8 from Christophe Lyon --- Thanks! Hopefully this will make the buildbots pass. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #12 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=e9a20a419b66431766e59dec75265ccdc0bf1046 commit e9a20a419b66431766e59dec75265ccdc0bf1046 Author: Alan Modra Date: Thu Nov 10 09:33:08 2022 +1030 Re: ld: Always output local symbol for relocatable link Remove this code dating back to commit 98790d3a95fc entirely, what it was trying to do is done elsewhere. PR ld/29761 * elflink.c (elf_link_output_symstrtab): Don't handle symbols in SEC_EXCLUDE sections here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #13 from Alan Modra --- fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] objcopy converts ELF relocatable object to PE that cause a ld segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #6 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=38c917d808fdb570ddb1215ccf8233a10484ba91 commit 38c917d808fdb570ddb1215ccf8233a10484ba91 Author: Alan Modra Date: Sat Nov 19 08:33:20 2022 +1030 PR29807, SIGSEGV when linking fuzzed PE object PR 29807 * cofflink.c (_bfd_coff_generic_relocate_section): Skip relocs against symbols with a NULL section. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #14 from Stas Sergeev --- Thanks, so with this fix I suppose the symbol in the last test-case no longer loses its name. But is it really removed as it should be per comment #10? -- You are receiving this mail because: You are on the CC list for the bug.
