[Bug binutils/31062] objdump -s missing option to dump uncompressed contents of compressed debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=31062 --- Comment #8 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=fab62191f84583780c2c6d024d0e583400881770 commit fab62191f84583780c2c6d024d0e583400881770 Author: Nick Clifton Date: Tue Nov 14 10:57:58 2023 + Improve objdump's handling of compressed sections. PR 31062 * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option. * NEWS: Mention the new feature. * doc/binutils.texi: Document the new feature. * testsuite/binutils-all/objdump.s: Update expected output. * testsuite/binutils-all/objdump.exp: Add test of -Z -s. * testsuite/binutils-all/objdump.Zs: New file. * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions. Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31062] objdump -s missing option to dump uncompressed contents of compressed debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=31062 Nick Clifton changed: What|Removed |Added Attachment #15220|0 |1 is obsolete|| --- Comment #9 from Nick Clifton --- Created attachment 15221 --> https://sourceware.org/bugzilla/attachment.cgi?id=15221&action=edit Proposed patch Extended patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31062] objdump -s missing option to dump uncompressed contents of compressed debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=31062 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Nick Clifton --- Hi Andreas, Right I have committed an extended version of the patch which adds a "COMPRESSED" flag to the section headers display, an entry in the NEWS file, a description of the new command line option in the documentation and a test to the testsuite. I also took this opportunity to tweak the code in readelf which does basically the same thing as objdump's code. I moved two sets of similar code into a single function and added a warning note to the output when displaying the contents of a compressed section in its compressed form. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #24 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=b2a6584d753a4dc94139e98c6998f570ed1e2341 commit b2a6584d753a4dc94139e98c6998f570ed1e2341 Author: Nick Clifton Date: Tue Nov 14 11:24:58 2023 + Fix another linker command line option that was not being recognised in its long form. PR 28910 * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #25 from Nick Clifton --- As I suspected there was another long option which was not being recognised. I have pushed a patch to fix that, and I think that the rest should be OK, so I am closing this PR for now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #26 from Jan-Benedict Glaw --- All mass compilations of Binutils worked as expected. Linux kernel builds are running, but no other regressions (and parisc and sh are fixed.) Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
Re: MIPS32 - binutils-2.41
Hi Pete, I've been attempting to build a cross-compiler for a MIPS32 microcontroller (specifically an M14KE) and I've been running into problems that appear to stem from binutils silently coalescing 'mips32' into 'mips64'. What specifically are these problems ? All configurations of the binutils for mips targets suppport at least one 64-bit variant. Most also support a 32-bit variant. But you may need to explicitly specifiy which variant you want when you are assembling something. It depends upon the exact configuration used and vpu that you wish to target. ./configure --target=mips32-none-eabi I do not believe that there is an eabi variant of the mips configuration so it is possible that this might be related to the problems that you are having. I've had a look in bfd/config.bfd and tried several variations of target, such as mips-none-eabi, mips-none-elf, mips32-none-elf, mips32- elf, etc. and they all seem to do the same thing. Well there definitely are mips-elf and mips32-elf configurations so those should work. Cheers Nick
Re: MIPS32 - binutils-2.41
Afternoon, Nick. Thanks for getting back to me. On Tue, 2023-11-14 at 12:28 +, Nick Clifton wrote: > Hi Pete, > > > I've been attempting to build a cross-compiler for a MIPS32 > > microcontroller (specifically an M14KE) and I've been running into > > problems that appear to stem from binutils silently coalescing > > 'mips32' > > into 'mips64'. > > What specifically are these problems ? The initial problem was that when I was building gcc after what I thought was a successful binutils build but there were complaints about incompatible ABIs. I tracked this back to what I thought was the binutils configure script assuming a 64-bit CPU even though my triplet started with 'mips32-'. I believe it's the target normalisation in config.sub (line 1055) that does it: mips3*-*) cpu=mips64 ;; That doesn't seem quite right to me but I don't know much about binutils to know what the rationale is for that transformation. Since posting I've tried a few other triplets and gone down another few dead ends that cause gcc / ld mismatches (littlemips vs. tradlittlemips for example with a 'mipsel-none-elf' target) but I think I've cracked it. Imagination used to distribute a pre-built toolchain for this microcontroller and they targetted 'mips-mti-elf', which I can see sets various options which the non-vendor targets don't. TL;DR - I've got something that (I think...) works now by using 'mips- mti-elf', but I'm unsure whether my initial post about the 'mips32-*' targets being silently coalesced into 'mips64-*' by the configure scripts is a bug or not, nor what the fix would be. I'm happy to raise a bug report if you think that config.sub clause is a typo. Cheers, Pete Restall
Re: MIPS32 - binutils-2.41
Hi Pete, I believe it's the target normalisation in config.sub (line 1055) that does it: mips3*-*) cpu=mips64 ;; Interesting... That doesn't seem quite right to me but I don't know much about binutils to know what the rationale is for that transformation. I have no idea why that is there, but it does look strange, I agree. In this particular case however the binutils are not to blame as the config.sub file (and the config.guess file) are actually taken from a different project: https://savannah.gnu.org/projects/config/ We just use copies of the files from that project. We synchronize the files occasionally, usually just before an official release. TL;DR - I've got something that (I think...) works now by using 'mips- mti-elf', Good, I shall now stop panicking. :-) but I'm unsure whether my initial post about the 'mips32-*' targets being silently coalesced into 'mips64-*' by the configure scripts is a bug or not, nor what the fix would be. I'm happy to raise a bug report if you think that config.sub clause is a typo. If you feel motivated, please do take this issue up with the config project. If it caused problems for you then it is likely to cause problems for other people in the future. So fixing it, or at least adding a comment explaining the reasoning to the config.sub file, would be a good thing. Cheers Nick
[Bug ld/31067] New: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
https://sourceware.org/bugzilla/show_bug.cgi?id=31067 Bug ID: 31067 Summary: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM Product: binutils Version: 2.42 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rearnsha at sourceware dot org Target Milestone: --- Created attachment 15222 --> https://sourceware.org/bugzilla/attachment.cgi?id=15222&action=edit bug demonstrator If a function with an associated .gnu.warning. section is dragged into a link set then the warning will be emitted even if is later discarded entirely by --gc-sections. See the attached testcase as a trivial example. This is a reduction from a real-world example where the whole printf functionality was eliminated from a program, but the warning from _write in newlib's libnosys.a was still emitted. -- You are receiving this mail because: You are on the CC list for the bug.
