[Bug ld/32190] [2.44 Regression] pr22393 test failures
https://sourceware.org/bugzilla/show_bug.cgi?id=32190 --- Comment #2 from Nick Clifton --- Hi H.J. Personally I think that this is a case where the test itself should be changed. Or at least made conditional upon --rosegment not being in effect. Or changed so that it does not complain about .note.build-id and .note.gnu.property sections being present in the read-execute segment. > Since -z separate-code is passed to linker, there shouldn't be mixed rodata > and text section in a page. True - but - the rodata that is there are notes rather than program data, and whilst it is still theoretically possible that these notes will mimic valid instructions, possibly even exploitable instruction sequences, the chances of this happening are very low. The reason for the commit is that GDB has been relying upon the fact that the linker would place the .note.build-id section in the first page of the executable image. This matters because when the kernel generates a core dump, it includes the first page of the executable in the dump. If the .note.build-id section is present in this page then GDB can locate it and use the information to track down the debug info file associated with the executable whose failure triggered the core dump. Of course it would be nice if there was another way for GDB to discover this information, but I do not think that it is a practical solution. It would probably involve kernel changes, gdb changes, and maybe even linker changes. All of which would have to be coordinated and all of which would probably not be backwards compatible. What do you think - are you willing to accept a change to the test itself ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-09-09 --- Comment #24 from Nick Clifton --- Doh - nope - mainly because I have been on holiday. OK - so are we happy with the latest version of the patch ? If so then I will go ahead and apply it. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32100] New: --rosegment moves the build-id note away from the start of the file
https://sourceware.org/bugzilla/show_bug.cgi?id=32100 Bug ID: 32100 Summary: --rosegment moves the build-id note away from the start of the file Product: binutils Version: 2.43 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nickc at redhat dot com Target Milestone: --- As reported here: https://sourceware.org/pipermail/binutils/2024-August/136267.html When linking binaries with --rosegment enabled the .note.build-id section is moved away from the ELF headers. This causes problems for GDB since it relies upon the fact that when the kernel creates core dumps it includes the first page of the executable's memory map. A page which used to include the .note.build-id section. With this information GDB is able to further process the core file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31954] [ld] [lto] [clang] using ld and lto, crash while dynamic compile executable
https://sourceware.org/bugzilla/show_bug.cgi?id=31954 --- Comment #4 from Nick Clifton --- Hi Hanwei, Thanks for uploading the object files. As I suspected however, on their own they are not enough to trigger the bug. For example a I tried test, based upon the command line you provided, but with the system files and libraries removed, and it worked: $ ld -pie --be8 -EB -z relro --hash-style=gnu --eh-frame-hdr -m armelfb_linux_eabi -o g++-dg-lto-200811125.exe -plugin /usr/lib64/LLVMgold.so -plugin-opt=mcpu=generic cp_lto_20081125_0.o cp_lto_20081125_1.o -e 0 $ echo $? 0 I suspect that the problem is related to the fact that you are targeting a big-endian ARM system. (The little-endian version tends to get more testing than the big-endian version). Given that you do have the full linker command line available, are you able to run the linker under GDB and find out where the seg-fault is happening ? And what is causing it ? A null pointer ? Accessing freed memory ? Something else ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31954] [ld] [lto] [clang] using ld and lto, crash while dynamic compile executable
https://sourceware.org/bugzilla/show_bug.cgi?id=31954 --- Comment #1 from Nick Clifton --- Hi Hanwei, Would you be able to upload the cp_lto_20081125_0.o and cp_lto_20081125_1.o object files so that we can try reproducing the problem without requiring the installation of a clang compiler. Are you able to capture the linker command line that is being executed ? Does the problem persist if you use a newer version of the linker, eg 2.42 or the mainline development sources ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31940] usage text for strings gives '--unicode=show' as a valid option
https://sourceware.org/bugzilla/show_bug.cgi?id=31940 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Aapo, Thanks for reporting this bug. It was all my fault. I changed the name of the option from 'show' to 'locale' whilst I was writing the patch to implement the --unicode option and I forgot to change the --help output. I have gone ahead and applied your patch. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32035] heap overlfow in readelf (binutils/dwarf.c:3648)
https://sourceware.org/bugzilla/show_bug.cgi?id=32035 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Hi Jaehoon Jang, Thank you for reporting this problem. As it happens this bug has already been fixed. If you try building the binutils from the mainline development sources or the 2.43 pre-release snapshot then you find that the issue is resolved. https://sourceware.org/pub/binutils/snapshots/binutils-2.42.90.tar.xz Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31972] strip cause SIGKILL in macOS
https://sourceware.org/bugzilla/show_bug.cgi?id=31972 Nick Clifton changed: What|Removed |Added Last reconfirmed||2024-07-26 CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Nick Clifton --- Hi Kei, This looks like it is a duplicate of: https://sourceware.org/bugzilla/show_bug.cgi?id=31571 Either way, it seems that we need to reject version 2 ARM64 Mach-O binaries. (Unless someone wants to add support for them). Would it be possible for you to upload a small test binary for me to use, so that I can try out some solutions ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32002] Untranslated plural in readelf.c:9433
https://sourceware.org/bugzilla/show_bug.cgi?id=32002 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Frederic, Sorry about that. I have applied the change that you have suggested. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/32018] Compilation of binutils 2.43 for riscv64-unknown-linux-gnu failed on CentOS 6
https://sourceware.org/bugzilla/show_bug.cgi?id=32018 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #11 from Nick Clifton --- Created attachment 15644 --> https://sourceware.org/bugzilla/attachment.cgi?id=15644&action=edit Proposed patch The uploaded patch is one possible way to avoid this problem. I do not like it very much, but it was the only way that I could think of to solve the problem without renaming the 'strchr' field in the CollectorUtilFuncs structure. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31395] Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=31395 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Hi Brooks, Sorry for the long delay in responding. I have been super busy lately. Anyway, I like the idea of a simple patch which will solve the problem for now, so I have gone ahead and checked in the change you reported. If this issue resurfaces please feel free to reopen this PR. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #17 from Nick Clifton --- Hi Pali, I am seeing new linker testsuite failures with these tests added: FAIL: ld-pe/symbols-ordinals-hints-imports-ld FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool Looking in the logs there appear to be some problems with symbol references: ./ld-new: cannot export sym1: symbol not defined ./ld-new: cannot export sym2: symbol not defined ./ld-new: cannot export sym3: symbol not defined ./ld-new: cannot export sym4: symbol not defined ./ld-new: cannot export sym5: symbol not defined And: ./ld-new: tmpdir/symbols-ordinals-hints-call-imports.o:fake:(.text+0x1): undefined reference to `__imp__sym1' ./ld-new: tmpdir/symbols-ordinals-hints-call-imports.o:fake:(.text+0x6): undefined reference to `__imp__sym2' ./ld-new: tmpdir/symbols-ordinals-hints-call-imports.o:fake:(.text+0xb): undefined reference to `__imp__sym3' ./ld-new: tmpdir/symbols-ordinals-hints-call-imports.o:fake:(.text+0x10): undefined reference to `__imp__sym4' ./ld-new: tmpdir/symbols-ordinals-hints-call-imports.o:fake:(.text+0x15): undefined reference to `__imp__sym5' Do the tests need to be rebased to match the current sources ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #16 from Nick Clifton --- No - but I am doing so now... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #21 from Nick Clifton --- (In reply to Rostislav Krasny from comment #20) Hi Rostislav (Sorry for the delay in replying - I am a bit overwhelmed at the moment). > Ok. Then what is the reason of generating VERSION_DATE from ChangeLog.git or > from the current date? These methods are meant to handle the case where the sources are not in a clone of the repository and not from a release tarball. > If this is done in case of a snapshot version, how > that snapshot version is made? Isn't it a regular tarball created by the > src-release.sh script sometime between official releases? Yes - in fact there is now a script on Sourceware that creates snapshots each time a commit is applied to the repository. > I just thought only three cases of the configure script being running are > possible: [1] building directly from the Git repo, [2] making a tarball > (release/snapshot/whatever) by the src-release.sh script from the Git repo, > and [3] building (release/snapshot/whatever) from a tarball previously > created in case 2. Only in cases 1 and 2 the configure script needs to > generate version.h and the $VERSION_DATE value, and in case 3 it should do > nothing about version.h and $VERSION_DATE because version.h is already > existing in the tarball. Right? Right - and this is what the fourth version of the patch does. >> I also found that the "git rev-parse --is-inside-work-tree" does not work >> as desired. If run outside of a repository it returns a fatal error and >> stops the rest of the scriptlet from running. So I have replaced it with >> a test for the .git directory at the top level of the source tree. Which >> I think should always work. > Does the configure script have 'set -e' somewhere? It does, but only inside the as_fn_exit() routine. > I didn't find it. Otherwise why the configure script stops in this case? I have no idea. I just found that it happened. Rather than investigate the cause however I just decided to use an alternative mechanism for checking for the existence of the git repository. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Hi Pali, The patches are fine. I have gone ahead and checked them in. Thanks very much for solving this issue. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31953] Show PE objdump -P versions in human readable form
https://sourceware.org/bugzilla/show_bug.cgi?id=31953 --- Comment #5 from Nick Clifton --- Sorry - I am taking a look now... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881
Nick Clifton changed:
What|Removed |Added
Attachment #15626|0 |1
is obsolete||
--- Comment #19 from Nick Clifton ---
Created attachment 15636
--> https://sourceware.org/bugzilla/attachment.cgi?id=15636&action=edit
Proposed patch
> Why to generate the VERSION_DATE and the version.h
> file if building from a source tarball?
Err, because I did not think to check. Doh!
> If any source tarball created by the src-release.sh it already contains
> the generated version.h file with properly generated VERSION_DATE from
> the last commit in the Git repo. I think in case of source tarball the
> configure script should not try to generate the version.h again because
> it already exist.
Yes - this is what should happen.
> This line in your patch assumes the date could always be found in
> the very first line of the change log file:
>
> VERSION_DATE=$(head -1 $srcdir/ChangeLog.git | cut -b 1-10 | sed -e s/-//g)
True - the assumption might be true most of the time, but you are
correct - the code should not rely upon it.
> What do you think about changing that code into the following one?
>
> VERSION_DATE=$(grep -m 1 -Po '^\d{4}-\d{2}-\d{2}(?=\s+)'
> $srcdir/ChangeLog.git | sed s/-//g)
Much better. The uploaded new patch includes this change.
> I also don't see the ChangeLog.git file anywhere in the Git repo
> of binutils. Did you mean ChangeLog file?
No - the ChangeLog.git file is created as part of the binutils
release process, so it should always be present in release tarballs,
but absent from the git repository.
I also found that the "git rev-parse --is-inside-work-tree" does not work
as desired. If run outside of a repository it returns a fatal error and
stops the rest of the scriptlet from running. So I have replaced it with
a test for the .git directory at the top level of the source tree. Which
I think should always work.
So - please can you look over this revision of the patch and let me know
what you think ?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 Nick Clifton changed: What|Removed |Added Attachment #15596|0 |1 is obsolete|| Attachment #15616|0 |1 is obsolete|| --- Comment #17 from Nick Clifton --- Created attachment 15626 --> https://sourceware.org/bugzilla/attachment.cgi?id=15626&action=edit Proposed patch Hi Guys, OK, what do you think of this version ? It incorporates Rostilav's suggested change, along with extra code to generate a date if building from a source tarball rather than repository sources Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #16 from Nick Clifton --- (In reply to Rostislav Krasny from comment #13) > The last question is: will the bfd/configure script be ran by the > src-release.sh script only or also by a user who want to build from an > already created tarball? A good point, and something that I missed in my version of your patch. The answer is both. > In case of an already created tarball that part of > the bfd/configure script should not be ran because the bfd/version.h is > already created during creation of the tarball and also because there is no > Git repo available. > > If the bfd/configure us always running I propose to change this line: > > VERSION_DATE=$(cd $srcdir ; git log -1 --format=%cd --date=format:%Y%m%d) > > into that line: > > VERSION_DATE=$(cd $srcdir && git rev-parse --is-inside-work-tree > /dev/null > 2>&1 && git log -1 --format=%cd --date=format:%Y%m%d) > > And then generate the bfd/version.h file only if the $VERSION_DATE is not > empty. Thanks - I will give this a try. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #15 from Nick Clifton --- (In reply to Rostislav Krasny from comment #14) > (In reply to Andreas Schwab from comment #12) > > That won't work with a snapshot. > > Is it the same to what I tried to fix in my previous message? Yes - sorry - I missed that message and did not take into account the problem with snapshots. I think that it should be possible to work around the issue - by using the date of the configure.ac file instead - but I need to make sure that this will work. Hmm - actually that might not work, since different people building the binutils from a snapshot or source tarball will see different dates... I need to think about this some more. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #11 from Nick Clifton --- Created attachment 15616 --> https://sourceware.org/bugzilla/attachment.cgi?id=15616&action=edit Proposed patch Sorry for dropping this. I have uploaded a revised version of your patch which: 1. Moves the configure.ac alterations into the bfd/configure.ac 2. Adds support for running the configure script in a build directory that is separate from the source directory (which is encouraged for building the binutils). I have tested the patch locally and it works for me, but I would like you to have a look over it first, before I commit it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- Feature added. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964
--- Comment #6 from Nick Clifton ---
(In reply to Jakub Jelinek from comment #5)
> 1) @command{uuencode} program's @code{-m} option
>I think base64 program from coreutils is more common than uuencode from
> sharutils,
>so either mention just that, or both. For no line wrapping base64 has -w
> 0 option.
That is a fair point. I will change the example to use the base64 program as
you suggested.
> 2) I don't know how FRAG_APPEND_1_CHAR is expensive compared to say
> appending more
It is actually pretty fast unless the specific backend involved needs to do
something funky.
> Just running coreutils base64 on 261M file
> took around 1s and base64 -d of that too.
I tried a similar test using /usr/bin/lto-dump (29Mb) and it took the assembler
less than a second to convert the base64 encoded version of the file into an
object file containing the binary.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964 --- Comment #4 from Nick Clifton --- Created attachment 15612 --> https://sourceware.org/bugzilla/attachment.cgi?id=15612&action=edit Proposed patch Hi Jakub, Would you like to try out this patch ? With it applied you can use the .base64 directive as you outlined in your description. The patch allows for multiple comma separated strings to be specified for a single .base64 pseudo-op because this is in keeping with how other assembler pseudo-ops behave. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31964] Add directive for more efficient encoding of binary data
https://sourceware.org/bugzilla/show_bug.cgi?id=31964 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Jakub, Does libiberty (or some other library) have a base64 decoding function ? If not, I guess I will have to steal^H^H^H^H borrow some code from some other project. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
--- Comment #9 from Nick Clifton ---
(In reply to Harmen Stoppels from comment #8)
> I appreciate the patch. Would an additional
> `ld_plugin_remove_extra_library_path(const char *path)` be possible so that
>
> > This does however present a problem if multiple archives with
> > @samp{__.LIBDEP} entries are present as they will all be handled by the
> > libdep plugin and thus they will share library search paths. This could
> > result in a library being loaded from an unexpected location.
>
> can be removed from the documentation?
Yes, but I do not think that it would work. The problem is that the search
paths and archive filenames are added to lists inside the linker by the plugin
calls to set_extra_library_path() and add_input_library() but these lists are
not scanned until later. So we would still end up with the potential for
multiple library search paths being recorded by the plugin but not being
actually used until the archives are
loaded later on.
> My only worry with the patch is that if libdep.so proves useful, and it
> would ever be promoted to a builtin flag `ld --resolve-static-deps` or even
> enabled by default, then `enum search_dir_source` may be hard to remove even
> though it's effectively unused.
I think that it is useful/needed. At least for now.
I am going to go ahead and apply the patch. If we need to make improvements or
changes we can always do so in the future.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 --- Comment #7 from Nick Clifton --- Hi Pali, Thanks for the update. I have checked in your patch. Are we good now ? I am really not a PE expert, so I am basically relying upon you to tell me what needs to be done, and if possible, provide the patches to do it. :-) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)
https://sourceware.org/bugzilla/show_bug.cgi?id=20814 --- Comment #11 from Nick Clifton --- Done -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31930] Error: cannot represent relocation type BFD_RELOC_64 for x86_64-w64-mingw32 target
https://sourceware.org/bugzilla/show_bug.cgi?id=31930 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- It is more likely to be a compiler error - since it appears that the compiler is generating assembler output that the assembler does not support. But it might be an assembler bug, or even bad high level source code. Can you upload the /tmp/ccB3ep8k.s file so that we can take a look ? (Assuming that it does not contain any proprietary information). >From the context it looks like the assembler is attempting to handle a 64-bit value in a way that is not supported by the 32-bit mingw32 format. But exactly why this is happening I do not know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 Nick Clifton changed: What|Removed |Added Attachment #15593|0 |1 is obsolete|| --- Comment #7 from Nick Clifton --- Created attachment 15597 --> https://sourceware.org/bugzilla/attachment.cgi?id=15597&action=edit Proposed patch And here is a second version of the patch which addresses both of the issues with the first version. It includes a test case to make sure that the libdep plugin continues to work as expected, and it records which plugin added which library search path, so that plugin sourced search paths are only used when attempting to locate libraries sourced from the same plugin. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #6 from Nick Clifton --- Oh, and it is possible that there are going to be conflicts with the lto-plugin, which also adds library search paths. I need to look into this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #5 from Nick Clifton --- Created attachment 15593 --> https://sourceware.org/bugzilla/attachment.cgi?id=15593&action=edit Proposed patch Hi Herman, OK, please could you try out this patch ? It is incomplete - I need to add a new test case and probably update the documentation as well - but I think that it does what is needed. In theory it will work if multiple search paths and libraries are specified in the __.LIBDEP entry, although I have not tested this. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 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/20880] [LD] [Bug] Wrong Hint Value For ImportLib IDATA6
https://sourceware.org/bugzilla/show_bug.cgi?id=20880 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #15 from Nick Clifton --- OK, done -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Hi Giacomo, It was a different bug, but in the same function. Fortunately one patch was able to resolve all four of your new testcases. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Nick Clifton changed: What|Removed |Added Assignee|amodra at gmail dot com|nickc at redhat dot com CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last reconfirmed||2024-06-24 --- Comment #3 from Nick Clifton --- Hi Harmen, > That is the real problem: object local search paths for dependencies are > transformed into global search paths in the bfd linker. Agreed. This is definitely the problem. > Finally, consider the motivating example in the documentation > https://sourceware.org/binutils/docs/ld/libdep-Plugin.html: > > > For example, given a library libssl.a that depends on another library > > libcrypto.a which may be found in /usr/local/lib, the ‘__.LIBDEP’ member of > > libssl.a would contain > > -L/usr/local/lib -lcrypto > > It is incredibly likely that `libssl.a` is in a default/system search path > like /usr/lib. The wrong libssl.a will be linked and nobody will notice > (unless it causes a linking failure, which is unlikely). It's highly > unexpected from a user's perspective that the dependency is resolved to a > path different from that specified in the archive, don't you agree? I do. And short of fixing the bfd linker's not-having-local-search-paths issue, which I think might be hard to do, the only other idea I have is to add a linker option to generate warning messages whenever a library can be found in multiple locations, and to enable this option by default when a plugin uses the set_extra_library_path() function. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 --- Comment #5 from Nick Clifton --- Hi Harmen, (In reply to Harmen Stoppels from comment #3) > I submitted a patch that addresses the issues reported here as well as > others https://sourceware.org/pipermail/binutils/2024-June/134936.html I have gone ahead and applied your patch. I agree that the change in the handling of the \ character is a non-issue since it never worked properly in the first place. I had to make one small change to the patch - apart from a few minor formatting tidy ups - which was to make the new parse_libdep() function static rather than global. The global form was triggering a warning from my compiler about the lack of a prototype for the function... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31921] [ARM][2.36] Linker produces bad executable
https://sourceware.org/bugzilla/show_bug.cgi?id=31921 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Christoph, Given that this a solved problem and that the 2.36 release is over 3 years old now, do you really need to know how/when the bug was actually fixed ? Looking at the file Linker_Bug/Debug/Linker_bug.map (which I assume is for the good build) it appears that the missing code is contained in the file: C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crtn.o Which seems a little odd to me since the code that is present appears to come from the crti.o file from the same directory. (I would not expect the code for a single init function to be split across two object files). Unfortunately without the files to examine, I cannot be sure. There does not appear to be a linker map file for the bad build, and without access to those system files I cannot run the build myself. But if you can, then maybe the map file will show what has happened to the .init section from the crtn.o object file. You state that the difference between the good and bad links is that fact that a different LMA/VMA relationship is used. But when I checked the scripts in the zip file you provided this did not appear to be the case: $ diff STM32H563AIIXQ_FLASH2RAM_BAD.ld STM32H563AIIXQ_FLASH2RAM_GOOD.ld 79a80,85 > . = ALIGN(4); > __exidx_start = .; > *(.ARM.exidx*) > __exidx_end = .; > . = ALIGN(4); > 124,127d129 < __exidx_start = .; < *(.ARM.exidx*) < __exidx_end = .; < Have I missed something ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Herman, It is all in a name ... The problem is that there is a libg.a in the standard library search paths and this is being picked up instead of your local libg.a. (Because the libdep plugin adds the new library search path to the end of the list of places to search). To see this, try adding the -Wl,--verbose option to the final cc command line. In my tests I get output like this: [...] attempt to open f/libg.so failed attempt to open f/libg.a failed attempt to open /usr/lib/gcc/x86_64-redhat-linux/13/libg.so failed attempt to open /usr/lib/gcc/x86_64-redhat-linux/13/libg.a failed attempt to open /usr/lib64/libg.so failed attempt to open /usr/lib64/libg.a succeeded [...] ld: f/libf.a(f.o): in function `f': :(.text+0xa): undefined reference to `g' If you change the name of your library to, say, libgg.a and adjust the makefile accordingly then it all works: [...] got deps for library f/libf.a: -Ltests/g -lgg [...] attempt to open /usr/lib64/libgg.a failed [...] attempt to open tests/g/libgg.a succeeded [...] Now I expect that you are going to say that the bfd linker ought to insert search paths derived from the libdep plugin *before* other search paths. But I would argue that this is a serious security risk. Searching for libraries in non-standard locations is a bad idea, especially for system libraries. So, if anything, I would say that the real problem is that the gold linker did not fail this test... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 --- Comment #2 from Nick Clifton --- s/and/an/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||nickc at redhat dot com Last reconfirmed||2024-06-21 --- Comment #1 from Nick Clifton --- Created attachment 15589 --> https://sourceware.org/bugzilla/attachment.cgi?id=15589&action=edit Proposed patch Hi Harmon, I think that this is (mostly) and off-by-error in the libdep sources. Please could you try out this patch and let me know how you get on. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31895] LD segfault in libbfd with --as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=31895 --- Comment #7 from Nick Clifton --- (In reply to Corentin Silva Pereira from comment #6) Hi Corentin, > Program received signal SIGILL, Illegal instruction. A SIGILL is very suspicious and indicates that there may well be some kind of hardware/memory problem with the machine that you are using. > I tried what Nick said about the fprintf, and the segfault didn't appear for > now, Which again makes me think that the problem could be unrelated to the binutils source code itself, but rather an issue with the runtime environment. > I'm gonna try with another version (more recent) of binutils to see if the > problem occurs too. Are you able to try running the test on a different machine as well ? That might provide some interesting results... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31895] LD segfault in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=31895
--- Comment #3 from Nick Clifton ---
(In reply to Corentin Silva Pereira from comment #2)
< Just so you can have more context, our software is developped with QT C++,
> and we have a lot of .o and .so files to link with the main software of our
> solution. One command can link like a 100 files/lib. This is the one that's
> causing this crash.
Just a thought - could your machine be running out of memory ? Given that
the build is so big, maybe there is a memory allocation in the linker
somewhere that is failing (and not being caught) which then goes on to
cause the problems you are seeing.
> Unfortunately, i can't give you the ld command i use because the code
> belongs to my company and i'm not authorized to give it.
That is a shame, but I understand.
> Although i tried to
> compile binutils 2.34 manually and i managed to cause the segfault within
> GDB.
>
> Here's what i got :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x55600b03 in elf_link_add_object_symbols (info=,
> abfd=) at elflink.c:5262
> 5262non_ir_ref_dynamic = h->root.non_ir_ref_dynamic;
Interesting. The 'h' pointer should be valid as the code just before it is:
for (p = htab->root.table.table[i]; p != NULL; p = p->next)
{
h = (struct elf_link_hash_entry *) p;
But the code that follows does this:
if (h->root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
So maybe the problem is that this reassignment of 'h' results in a NUL
pointer.
I suspect however that GDB is mistaken about the line where the fault
is really happening...
> I tried to give -g -O0 to all binutils so i can have all the symbols, but i
> still can't print h or print h->root within GDB.
If you are able to build and run your own linker then you can easily insert
some fprintf() statements of your own in order to help find out what is going
on. (I do this all the time. GDB is great, but sometimes a good old fprintf
is what you need).
> > The 2.34 release of the binutils is quite old now. Are you able to update
> > to a newer version ?
> To answer your question, we are porting the software to Ubuntu 24.04 which
> uses a more recent version of binutils but i still have the problem on
> Ubuntu 24.04 so i don't think it is very related to the version.
You could always try downloading the latest binutils release and building it
for yourself.
I am not sure if looking for a solution this way will help though. Are you
required to use the system supplied version of the binutils when building your
project ? If so, then even if we can say, "oh yes this is a known bug, fixed
in version 2.XX" it will not help. Mind you, if you do have to use the system
supplied version of the binutils then you should really be contacting the
Ubuntu people and asking them for help. After all they are the ones that will
have to patch the linker, once the problem is found.
> Are there elements i can add to the binutils compiling arguments to give you
> more information ? For example, something to generate a coredump or
> something to read those optimized out values
Using fprintf()s is my best suggestion.
You might also find it worthwhile to experiment with using a different linker.
eg GOLD or LLD. It won't solve the BFD linker problem, but it will allow you
to get on with your own development work.
Trying to create a small test case that demonstrates the problem would be
helpful too - assuming that the code does not contain any code that your
employers do not wish to be made public.
Long term - you might want to consider breaking up the application into
smaller components. (If that is possible). Building and linking large
applications always takes a long time, and if you are able to instead just
build small components that then work together, you should find that
development time improves.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #6 from Nick Clifton --- (In reply to Rostislav Krasny from comment #4) > The /configure script is generated from the /configure.ac file, right? Right. > Then > the fix should be done in the /configure.ac and not directly in the > /configure script? Also correct. > What exact command is used to generate the /configure script from the > /configure.ac file? Well to be precise, it is the bfd/configure.ac file that ought to contain the code to generate the version.h file. (Since the top level configure.ac file is shared with the gcc project, and that project does not know or care about the bfd/ sub-directory). Also the bfd/configure file needs to be generated by autoconf version 2.69, rather than any later (or earlier) version. Whilst a bit old now the 2.69 version has been used by the gcc, gdb and binutils projects for a long time and it is know to work and do what we want. The official way to regenerate the configure file is to configure a build with the --enable-maintainer-mode option specified: mkdir build /configure --enable-maintainer-mode make all-bfd Building, or rebuilding this version of the binutils will automatically run autoconf and automake and aclocal in the correct way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Last reconfirmed||2024-06-18 Resolution|NOTABUG |--- --- Comment #12 from Nick Clifton --- I have posted a proposal for a patch which stops the linker from overwriting known source file types: https://sourceware.org/pipermail/binutils/2024-June/134886.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #11 from Nick Clifton --- (In reply to Jonathan Wakely from comment #10) > For the record, gcc won't even allow you to set the output to the name of an > input file: > > $ gcc foo.c -o foo.c > gcc: fatal error: input file ‘foo.c’ is the same as output file > compilation terminated. It is the same with ld: $ ld foo.o -o foo.o ld: input file 'foo.o' is the same as output file $ echo $? 1 But I still think that the linker could be a bit more paranoid about overwriting existing files, so I will see what I can do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31895] LD segfault in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=31895 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Corentin Silva Pereira from comment #0) Hi Corentin, > "collect2: fatal error: ld terminated with signal 11 [Erreur de > segmentation], core dumped" when compiling, Whilst this is obviously a bug in the linker, without knowing more about what you were doing, it is going to be impossible to determine the cause of this problem. > and i've looked in dmesg to find > an explanation. Using dmesg does not really help here, as it does not provide details about where in the linker the problem is occurring. > 7ffc282a3030 error 4 in libbfd-2.34-system.so[7f108e6dc000+b1000] The 2.34 release of the binutils is quite old now. Are you able to update to a newer version ? (Note - updating gcc does not necessarily update the binutils as well). Alternatively you could try downloading the binutils sources and creating your own linker. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #3 from Nick Clifton --- (In reply to Sam James from comment #1) > Nick, what do you think? Is it worth discussing it on the ML(s)? Yes, most definitely. > I agree with the criticism here - it's a pain to scroll through `git log` > as-is, and it's hard to see when real changes are made -> need to update our > branches/packages downstream. I also agree. I looked at git-version-gen but unfortunately I did not understand how it should be used. But I have a very small brain. :-} I do like the idea of the configure file generating the bfd/version.h file automatically however, so if someone wants to write a potential patch that would be great. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Nick Clifton changed: What|Removed |Added Last reconfirmed||2024-06-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #8 from Nick Clifton --- Hi Nilus, Hi Fanguri, I have checked in e8e10743f7b to add a --rosegment option the linker. This should address the size increase when -z separate-code is used. I am setting the state of this PR to 'waiting' as the patch is still brand new and there may well be problems with it that I have not anticipated. Cheers Nick PS. I have also committed 54904469f71 to fix some test case issues when the new option is enabled by default. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Nick Clifton --- (In reply to Rostislav Krasny from comment #17) > Reopened only to draw attention to the second patch. Oops - sorry - I meant to get to this last week, but ran out of time. I have now applied your patch, although I forgot to reference this PR in the commit message, which is why it does not show up in the message log. I will close the PR again, but do feel free to reopen it if there are more changes that you think are needed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31843] Segfault in objdump (bfd_get_section_contents)
https://sourceware.org/bugzilla/show_bug.cgi?id=31843 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Nick Clifton --- Hi Giacomo, Thanks for reporting this bug. I have checked in a small patch to add a check for a NULL section pointer. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Nick Clifton --- Hi Rostislav, Thanks for the updated patch and the DCO. I have now applied your patch to the sources. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Nick Clifton changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from Nick Clifton --- Hi Rostislav, Thanks - the patch looks great and I had no problems when I was testing it. There is just one thing though, in order to accept it we either need it signed with a Developer Certificate of Origin or else you need to complete a copyright assignment to the FSF. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #7 from Nick Clifton --- (In reply to Peter Damianov from comment #5) > Just to be completely clear, the command is incorrect, but the way ld reacts > to the mistake is the problem. In this case, the "file.c" will be deleted, > the user has potentially lost a file, and day ruined. I think refusing to > delete output here is the correct and preferable thing to do. It may seem callous, but if you are using command line tools to build programs then I would argue that a certain level of competence is expected, and that loosing a source file to a silly mistake is actually a useful lesson. But maybe a compromise solution can be reached here. As Alan pointed out, setting the output file name to the name of an existing source file is going to cause problems regardless of whether the link succeeds or fails. So maybe the correct thing to do is to have the "-o " option fail if the output name matches the name of an existing file *and* that name matches a pattern of known source files (eg *.[cChosS] *.cpp) ? What do you think ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #4 from Nick Clifton --- (In reply to Rostislav Krasny from comment #3) > In case you can't guarantee the "core.sharedRepository" configuration > property was set properly before the src-release.sh was ran you can, in > addition to setting umask in its beginning, also set the > "core.sharedRepository" Git configuration property near the umask command > and right after that run 'git reset --hard'. You can also add some check > that there is no uncommitted changes before the 'git reset --hard' is > actually run. Maybe this is the best solution. OK - would you like to submit a patch to that affect please ? (Your git-fu is obviously stronger than mine ... :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed||2024-05-28
Assignee|unassigned at sourceware dot org |nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
Hi Rostislav,
> After running this script permissions of all files and directories
> (including files of Git repo and the root directory of the project) are
> changed to 0777,
Well that does depend upon the user's umask setting.
> i.e. everything is open for everybody for any read-write
> operation. This is not good, not secure and must never be done.
Agreed.
> The src-release.sh script does it by the following line:
>
> chmod -R og=u . || chmod og=u `find . -print`
>
> Please remove this line. The src-release.sh works properly without that line
> and doesn't change permissions of files or directories.
Except that the permissions stored in the tarball will now be dependent upon
the environment in which the tarball was created. Which could be a problem
when creating reproducible tarballs.
How about rather than deleting the line we change it to:
find . -path "*/.git" -prune -o -exec chmod u=rwX,go=rX {} \;
This should ensure that none of the repo files are changed and that all other
files and directories are given explicit, reproducible permissions. Plus it
avoids the potential issue of a chmod command line that is far too long...
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Peter, Can I check your testcase please ? > gcc -o file.c -lm You appear to be creating an output file called "file.c", is that right ? You also do not appear to have an input file. I am assuming that the test shpould have been something like this: gcc -o foo file.c -lm And then the problem is that "foo" is overwritten. I would argue that the linker's behaviour is correct (and that lld and mold are wrong). The reason being that if the output file is not deleted then it is harder for a user or script to detect that a problem has occurred. Consider a scenario like this: If the link step fails, but does not delete the output file, then the user, not realizing that something went wrong, will run the old executable, see that it works and think that their change is correct. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31796] Internal error in write_function_pdata at obj-coff-seh
https://sourceware.org/bugzilla/show_bug.cgi?id=31796 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Nick Clifton --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31796] Internal error in write_function_pdata at obj-coff-seh
https://sourceware.org/bugzilla/show_bug.cgi?id=31796 --- Comment #3 from Nick Clifton --- Snafu - the AArch64 architecture was not being assigned a SEH type. Fixing... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31796] Internal error in write_function_pdata at obj-coff-seh
https://sourceware.org/bugzilla/show_bug.cgi?id=31796 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last reconfirmed||2024-05-28 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31726] et/config.ac etc/Makefile.am release
https://sourceware.org/bugzilla/show_bug.cgi?id=31726 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Nicolas, Oops - thanks for pointing this. I have checked in a small patch to the src-release.sh script - the one that is responsible for creating the release tarballs. It turns out that there are some other files in the etc/ directory which were also being (accidentally) omitted, so I have added those as well. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31395] Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=31395
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
(In reply to Brooks Davis from comment #0)
Hi Brooks,
> When invoked via gcc -m32 on a FreeBSD amd64 system, ld searches for
> DT_NEEDED libraries as though it were on an i386 system and thus fails
> to find them.
Err, maybe I am misunderstanding this, but doesn't using -m32 imply that the
linker should act as if it is building for an i386 system ?
> Confusingly that is true even though
> gcc passes -L/usr/lib/../lib32 to ld. I belive this is due to this
> logic:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldelf.c;
> h=04045acbf3dc56947edb15e5818dd5b69fd9;hb=HEAD#l1091
Which makes sense. That logic is duplicating how the system loader works, and
since the system loader does not have access to the -L options generated by
gcc, that code also ignores them.
> Further tracing shows that gcc attempts to communicate the correct paths
> via a LIBRARY_PATH variable, but I don't think binutils looks for that
> at all:
It doesn't - and nor does the system loader. But if gcc used LD_LIBRARY_PATH,
that might work.
Does FreeBSD support cross linking ? If not, then would a patch like this
solve your problem:
diff --git a/ld/configure.tgt b/ld/configure.tgt
index f937f78b876..a68f2313850 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -1113,7 +1113,7 @@ case "${target}" in
;;
*-*-freebsd*)
- NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib'
+ NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib /lib/lib32'
;;
hppa*64*-*-hpux11*)
How is the linker configured ?
In particular does it support the elf_i386_fsbd emulation ?
If it does, what shows up the SEARCH_DIR entries for that emulation's built in
script ? ie:
ld -m elf_i386_bfd --verbose | grep SEARCH_DIR
On my (cross-hosted) build I get:
SEARCH_DIR("/usr/local/i386-pc-freebsd/lib32");
SEARCH_DIR("/usr/local/i386-pc-freebsd/lib");
Which implies to me that the linker already knows about the /lib32 directory,
but since I am running a cross-hosted linker, it prepends
/usr/local/i386-pc-freebsd/ to the path.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31738] Improve objdump -p output of PE Import and Export Tables
https://sourceware.org/bugzilla/show_bug.cgi?id=31738 --- Comment #4 from Nick Clifton --- (In reply to Pali Rohár from comment #3) > Anyway, how to run that one exclude-symbols-def-i386.d test case? I build the binutils for the i686-pc-mingw32 target and then run the linker tests. That should exercise that particular test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31738] Improve objdump -p output of PE Import and Export Tables
https://sourceware.org/bugzilla/show_bug.cgi?id=31738 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Pali, Thanks for the patch. I agree that the output is better, so I have gone ahead and applied the change, although I did have to fix a couple of minor issues: 1) the patch would not build on 32-bit targets because there were a couple of places where it was trying to print out a 'long long' value using %lx and 2) the linker tests that use objdump -p on PE format files broke because of the new text. I have corrected both of these issues in the version of the patch that was checked in. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31728] dlltool generates incorrect hints in import libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=31728 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Pail, Commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d is a fix for PR 20814 and 20880. As you can tell, I am no expert with the PE file format, so I have tended to go with the solutions suggested by the bug reporters. Do you have a suggestion for a patch which will resolve both this PR and those PRs ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31722] [binutils/readelf] Missing eol in warning string index of converts to an offset of which is too big for section
https://sourceware.org/bugzilla/show_bug.cgi?id=31722 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Tom, Thanks for pointing this out. It turns out there are quite a few warning messages in that source file that are missing a terminating \n character so I have gone ahead and extended your patch to cover them all. (I hope ... I must admit I only performed a visual scan of the code. I did not a sophisticated grep of some kind). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31714] Static function pointer
https://sourceware.org/bugzilla/show_bug.cgi?id=31714 --- Comment #3 from Nick Clifton --- Created attachment 15510 --> https://sourceware.org/bugzilla/attachment.cgi?id=15510&action=edit script for performing binary searches on the binutils git repository -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31714] Static function pointer
https://sourceware.org/bugzilla/show_bug.cgi?id=31714 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to Bhavimani, Manjunath from comment #0) Hi Bhavimani, > With nxp gcc v10.2 and binutils 2.35, I observed that the data section for > all static variables of Task2 file is initialized properly, but not for the > other files (Task1 and Task3). > Our observation: When we moved to a higher version of gcc (i.e., v10.3 with > binutils v2.36), this issue is not observed. > Kindly let us know if this issue is already known. Yes - since it has obviously been fixed in the 2.36 release. > If yes, could you please > let us know the right patch version for v2.35? Not off the top of my head no. But you can always locate the patch needed yourself. I am going to upload the script I use to perform binary searches on the binutils repository. With this you should be able to locate the patch that fixed the problem. > Otherwise, this needs to be fixed in v2.35. Sorry, but 2.35 is so old now that we are not going to make any more changes to it. You can always contact whomever supplies you with your toolchain and ask them to update it. > Upgrading to the v10.3 toolchain is not within our project scope. In which case you may not be able to resolve this problem, even if you can find the patch that fixes the linker. Instead you may need to change your source code to use some other mechanism to achieve the goal that you desire. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31710] Segmentation fault using wrapping and debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=31710 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Roberto, Thanks for reporting this issue. The problem was a bug in a macro used to process relocations against global symbols. This macro assumed that a name lookup would always succeed and so did not check for a NULL return value. I have checked in a small patch to fix this problem. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30783] objdump -dl and -WL disagree about initial state interpretation of the DWARF FSM
https://sourceware.org/bugzilla/show_bug.cgi?id=30783 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Nick Clifton --- Great - patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30783] objdump -dl and -WL disagree about initial state interpretation of the DWARF FSM
https://sourceware.org/bugzilla/show_bug.cgi?id=30783 --- Comment #7 from Nick Clifton --- Created attachment 15481 --> https://sourceware.org/bugzilla/attachment.cgi?id=15481&action=edit Proposed patch Hi Achim, Thanks for the uploaded file. I think that I now understand the problem. Please could you try out the uploaded patch and let me know if it works for you ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31609] [readelf, -wL] Stmt column misaligned with -W
https://sourceware.org/bugzilla/show_bug.cgi?id=31609 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Tom, Are you sure ? The effect does not appear to happen for me. It might depend upon the width of the terminal window however. (I am using a terminal window with a width of 157 characters). In the tests I ran the 'x' always lined up with the last 't' in "Stmt". Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 Nick Clifton changed: What|Removed |Added Attachment #15467|0 |1 is obsolete|| --- Comment #11 from Nick Clifton --- Created attachment 15468 --> https://sourceware.org/bugzilla/attachment.cgi?id=15468&action=edit Proposed patch Like this ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 --- Comment #9 from Nick Clifton --- Hi Alan, > https://sourceware.org/bugzilla/show_bug.cgi?id=31540 > > --- Comment #8 from Alan Modra --- > Nick, your change to binutils/testsuite/binutils-all/pr25662.ld results in > arc-elf +FAIL: objcopy executable (pr25662) > arc-linux-uclibc +FAIL: objcopy executable (pr25662) > bfin-linux-uclibc +FAIL: objcopy executable (pr25662) > frv-linux-gnu +FAIL: objcopy executable (pr25662) > spu-elf +XPASS: objcopy executable (pr25662) Doh! That change was not even meant to go in. It was a potential patch for a completely different issue. I will revert my commit. Sorry about the mis-commmit! Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 Nick Clifton changed: What|Removed |Added Attachment #15461|0 |1 is obsolete|| Attachment #15463|0 |1 is obsolete|| --- Comment #9 from Nick Clifton --- Created attachment 15467 --> https://sourceware.org/bugzilla/attachment.cgi?id=15467&action=edit Proposed patch I dislike relying upon magic strings like "elf64-hppa", so how about this alternative patch which checks the vector itself ? (I also added a comment so that readers of the code will be directed to this PR if they are wondering why the test is needed). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31255] keyword arguments do not work with .altmacro
https://sourceware.org/bugzilla/show_bug.cgi?id=31255 --- Comment #4 from Nick Clifton --- I have updated the example in the assembler documentation to make it clear that the .altmacro pseudo-op is affecting the invocation of the macro, not the definition. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #19 from Nick Clifton --- Oops - I missed that too. Sorry. Patch applied as commit: ab0a395b54d Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Nick Clifton --- Hi Simon, Thanks for the revised patch. It looks a lot better to me now and so I have gone ahead and checked it in. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Nick Clifton --- Right - well the patch looks good to me, and did not trigger any problems, so I have gone ahead and checked it in. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31540] objcopy, ELF_SECTION_IN_SEGMENT_1 section to segment mapping seems wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=31540 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2024-04-15 Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to vijay Shankar from comment #2) > I have a patch suggestion for this issue I am running the patch through my test farm and so far it is looking good. Can you confirm that the patch fixes the problem you initially reported ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31255] keyword arguments do not work with .altmacro
https://sourceware.org/bugzilla/show_bug.cgi?id=31255 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at sourceware dot org |nickc at redhat dot com Resolution|--- |FIXED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Seanga, Thanks for reporting this problem. I have checked in a small patch to update the assembler's documentation. The .altmacro entry now includes: 'No passing arguments to macros based upon keyword assignment.' In altmacro mode arguments cannot be passed to macros by keyword assignment. and the .macro entry includes: Note however that when operating in altmacro mode arguments can only be specified by position, not keyword. Thus for example: .altmacro .macro foo bar=1, baz=2 .print "\bar \baz" .endm foo baz=3 Will print: baz=3 2 Rather than the expected: 1 3 Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30730] Building libheif for m68k_cf fails with Internal error in emit_expr_encoded at dw2gencfi.c:215
https://sourceware.org/bugzilla/show_bug.cgi?id=30730 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Giulio, Thanks for reporting this problem. Please could you upload the assembler output from the compiler (created when you add -S to the gcc command line), plus the command line that gcc invokes when it runs the assembler (use -v to see this). If you are using binutils 2.26.1 then I should point out that this is a really old release (we are up to version 2.42 now) and so it is quite likely that the bug has already been fixed. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #2 from Nick Clifton --- Created attachment 15461 --> https://sourceware.org/bugzilla/attachment.cgi?id=15461&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Clifton --- Hi Dave, This is slightly strange. The test is meant to check that the old style dynamic tags for BIND_NOW are generated, ie: $ readelf -d -W tmpdir/dump [...] 0x0018 (BIND_NOW) 0x6ffb (FLAGS_1)Flags: NOW But for the hppa64, both the new *and* old style tags are being generated: $ readelf -d -W tmpdir/dump [...] 0x001e (FLAGS) BIND_NOW 0x0003 (PLTGOT) 0x1308 0x0018 (BIND_NOW) 0x6ffb (FLAGS_1)Flags: NOW I am not sure why this is happening, but I do not see the harm in it. So I think that the best solution is to change the now-3 test to look for the old flags. Would you mind giving the uploaded patch a try and let me know if it works for you ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #13 from Nick Clifton --- (In reply to Simon Cook from comment #12) Hi Simon, > Patch with my suggested change, and done some testing pre-the previous fix > and with my change and verified UNC paths still work. (Tested using ld > loading static archives which was the case of this I found, I'm happy to do > any before/after validation on GDB if someone has some steps to reproduce > the original issue) + bool is_network_path = strncmp (filename, "//", 2) == 0 +|| strncmp (filename, "", 2) == 0; Won't this test falsely match DOS paths that start with: \\?\, eg \\?\D:foo\bar IE shouldn't the test be: bool is_network_path = strncmp (filename, "//", 2) == 0 || strncmp (filename, "?\\UNC\\", 8) == 0; Also, since we have a startswith() function the check could be simplified to: bool is_network_path = startswith (filename, "//") || startswith (filename, "?\\UNC\\"); > Submitting here since that's where the original patch was, but if you'd > rather me send it to the list, I'm happy doing that also. Either place is good... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Nick Clifton changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Ever confirmed|0 |1 Last reconfirmed||2024-04-10 --- Comment #9 from Nick Clifton --- (In reply to Simon Cook from comment #8) > 2. Implement an alternative to using PathIsNetworkPathA. From its > description, I think it might be possible to substitute that call for > something like `is_network_path = strncmp(filename, "//", 2) == 0 || > strncmp(filename, "", 2) == 0` since I think that's the behaviour we > actually care about. > > Any thoughts? Simpler is better in my opinion. But since I am not a UNC expert I do not know if the above test is sufficient. If it is then I would definitely suggest that we use it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31571] strip mangles 64-bit mach-o binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=31571 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Jubilee Young from comment #0) Hi Jubilee, > This issue may be constrained to aarch64 macOS. This is going to be a very hard problem (for me) to diagnose. Mainly because I do not have access to an AArch64 MacOS system. Are you willing to run some tests to help track down the cause ? > Part of the issue appears to be mangling the header. The green diff on the > right is what happens after a binary is mangled by strip. Generally speaking strip should not be mangling the header in this way, especially not the magic number. (I am not a MacOS expert, but I assume that the magic number is important and should not be changed). Judging by the change in magic number however it appears that strip has changed the output from a 64-bit format (BFD_MACH_O_MH_MAGIC_64) to 32-bit format (BFD_MACH_O_MH_MAGIC). Which is obviously wrong. Hmm, looking in the code, I think that I might see the problem. It appears that the BFD library does not support generating version 2 (0xFEEDFACF) format output. Take a look at the bfd_mach_o_arm64_mkobject() function in bfd/mach-o-aarch64.c (around line 57). I have no idea why this is the case. Nor how easy it would be to generate the version 2 format output. Do you fancy doing some binutils hacking of your own and seeing if you can either a) add support for the version 2 format or b) have version 2 format input rejected so that strip will not silently corrupt binaries ? Cheers Nick Assuming that this is correct -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31605] [readelf, -wL] Highlight empty address range
https://sourceware.org/bugzilla/show_bug.cgi?id=31605 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Tom de Vries from comment #0) Hi Tom, > I wonder if making this clear somehow using an annotation would be a good > idea. > > Say: > ... > File nameLine numberStarting addressViewStmt > > dw2-epilogue-begin.c 440x4101e8 x > dw2-epilogue-begin.c 47 ~0x4101ec x > dw2-epilogue-begin.c -0x4101ec A tilde seems too mild/easily missible/not immediately obvious to me... > Or displaying the address in parentheses. This might be better. But really it is not just the address that is not used, it is the entire line of source code as well. So maybe something like: dw2-epilogue-begin.c 270x40110d x [dw2-epilogue-begin.c 280x40 x] dw2-epilogue-begin.c 290x40 1 x dw2-epilogue-begin.c 300x401118 x Or: dw2-epilogue-begin.c 270x40110d x dw2-epilogue-begin.c (unused) 280x40 x dw2-epilogue-begin.c 290x40 1 x dw2-epilogue-begin.c 300x401118 x Whatever way is chosen, it will have to be optional and off by default as otherwise I am sure that it will break lots of things, not least of which is gdb's own testsuite. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #4 from Nick Clifton --- (In reply to Victor Do Nascimento from comment #3) Hi Victor, > Looking at `readelf -S ./libc.so.6', we see that the crash happens within > the .gnu.hash section of the elf file. This, combined with the fact we used > the -D flag when disassembling leads me to the conclusion that we're trying > to disassemble non-instruction bytes, which due to ill-luck, look an awful > lot like a valid instruction. Ah - that makes sense. > This thus seems like a quality of implementation issue. Normal disassembly > of executable sections of code appear to be functioning correctly, but I > guess a rethink is needed in terms of how assertions are used in disassembly. > > My impression is that their use in a context such as in the use of `objdump > --disassemble-all` ought be predicated on whether or not we're disassembling > in a strictly executable code-only section of the object file or not... In my opinion, the disassembler should never trigger an abort (or an assertion), even if it is being asked to decode an illegal bit sequence. Instead it should just display the bits with an annotation that they are illegal. In fact when a user is disassembling with the -D/--disassemble-all it should be clear that they expect illegal bit sequences to be encountered, and objdump should really be able to cope. (This also goes back to my long standing opinion that library functions should never call abort. Instead they should always report back to their caller that they have encountered some kind of problem, and allow the caller to decide what to do). My suggestion is that you change get_sreg_qualifier_from_value() so that it returns AARCH64_OPND_QLF_NIL if it encounters an error. (Or maybe a new aarch64_opnd_qualifier value such as AARCH64_OPND_QLF_ERR). And then update the callers of get_sreg_qualifier_from_value to take some kind of action if this result is returned. A bit if a hassle I know, but I think that it is the right thing to do. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #4 from Nick Clifton --- (In reply to Zhiqing Xiong from comment #3) > does this change will be released in GDB 15.1 ? Yes. Or maybe 14.3. I am not sure of the number of the next GDB release... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |victorldn at sourceware dot org Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Victor, Thanks very much for taking a look at this. :-) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Zhiqing, Thank you for reporting this issue and providing a solution. I have applied your patch to the sources. I am a little bit concerned that the shlwapi.h header file might not be present in all WIN32 development environments - but if necessary we can always add a configure time check to handle it absence. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Nick Clifton changed: What|Removed |Added Version|unspecified |2.43 (HEAD) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] New: Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Bug ID: 31595 Summary: Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nickc at redhat dot com Target Milestone: --- Attempting to disassemble the latest version of glibc compiled for the AArch64 for Fedora Rawhide results in: $ objdump -D lib64/libc.so.6 objdump: opcodes/aarch64-dis.c:251: get_sreg_qualifier_from_value: Assertion `value <= 0x4 && aarch64_get_qualifier_standard_value (qualifier) == value' failed. Abort (core dumped) This was using the version of libc.so.6 obtained from glibc-2.39.9000-10.fc41.aarch64.rpm but I can also reproduce the problem with a libc.so.6 from RHEL-9. I suspect that any recent-ish version of libc.so will do. I suspect that the issue is with the processing of the rcpc3 size field, since the stack backtrace shows that get_sreg_qualifier_from_value is called from do_special_decoding at opcodes/aarch64-dis.c:2678. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31445] -Trodata should throw a warning
https://sourceware.org/bugzilla/show_bug.cgi?id=31445 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Last reconfirmed||2024-03-19 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #6 from Nick Clifton --- Hi Jacob, It would really help if you were able to upload a small example to reproduce this problem. I have tried to create my own test case, but so far I cannot make the linker misbehave. The reason that the linker does not complain about the -Trodata option is that it is treating it as a shortened form of -Trodata-segment. (Any long option can be shortened providing that it is still distinguishable from other options). I suspect that the issue is that the linker is not creating separate segments for text and data, and so the .rodata section is just being placed after the .text section. This is the default behaviour for many architectures, including ARM. You might find that adding "-zseparate-code" to the linker command line will help. (Without a test case, I could not check this for myself). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31473] readelf --debug-dump=frames silently does nothing
https://sourceware.org/bugzilla/show_bug.cgi?id=31473 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Tom, Please can you upload the file for testing ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31474] Strip permission denied
https://sourceware.org/bugzilla/show_bug.cgi?id=31474 Nick Clifton changed: What|Removed |Added Last reconfirmed||2024-03-19 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Domenico Panella from comment #0) Hi Domenico, > I have a weird problem with strip command. > When I run "strip" command from a shell script, I get a permission denied > error. Can you detail the exact command please ? > Instead, if I run the same command from a terminal session, it works! > Is it a bug or do i wrong anything? This is probably a misunderstanding rather than a bug. The most likely cause is the choice of output directory. Strip works by creating a temporary file in the same directory as the output file. It then copies the input file into this temporary file, stripping it as it goes. Finally if everything has worked it deletes the output file and renames the temporary file to the output file. So if there is some reason why a new file cannot be created in the output directory then strip will fail. For example: strip foo -o /dev/null Will fail because ordinary users cannot create files in /dev, and they cannot delete /dev/null either. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31469] readelf: erronously says "Cannot decode 64-bit note in 32-bit build" in 64-bit build when dumping notes of core file
https://sourceware.org/bugzilla/show_bug.cgi?id=31469 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Berteun, > It seems to me the entire if statement should > have been removed, as removing the #ifndef only > now always makes it print it cannot decode a 64 > bit note, even in a 64 build. Previously this > statement would have been compiled out. Agreed. And done. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
