[Bug binutils/11983] libbfd reuses pointer passed to bfd_openr
https://sourceware.org/bugzilla/show_bug.cgi?id=11983 --- Comment #12 from Tom Tromey tromey at redhat dot com --- (In reply to Nick Clifton from comment #11) Hi Tom, On further reflection I think the patch as applied will cause gdb crashes. Due to the historical oddity of how the BFD's filename was handled, gdb chose to go its own route and reallocate the filename on the BFD's objalloc. Hang on - are you saying that GDB alters the contents of the filename field inside the BFD structure ? If so, then surely the correct thing to do now is to remove that piece of code from GDB. Yeah, that's what gdb does. I agree that it probably makes the most sense now to entirely remove gdb_bfd_stash_filename (contra a suggestion I saw on the mailing list). However it would be good to audit all the callers to be sure. Sorry for the roundabout responses, I'm away from real email for the time being. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11983] libbfd reuses pointer passed to bfd_openr
https://sourceware.org/bugzilla/show_bug.cgi?id=11983 --- Comment #9 from Tom Tromey tromey at redhat dot com --- Just FYI - you don't need the if before the free. free accepts a NULL pointer. There was a big sweep across nearly all GNU projects a few years ago to remove these redundant checks... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11983] libbfd reuses pointer passed to bfd_openr
https://sourceware.org/bugzilla/show_bug.cgi?id=11983 --- Comment #10 from Tom Tromey tromey at redhat dot com --- On further reflection I think the patch as applied will cause gdb crashes. Due to the historical oddity of how the BFD's filename was handled, gdb chose to go its own route and reallocate the filename on the BFD's objalloc. However the new patch requires the filename to be malloc'd -- but in gdb this will not be the case. Also IIRC from when I looked into this, some of the binutils also play games with the filename. I think a fuller audit is needed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11066] c++filt does not unmangle function types correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=11066 Tom Tromey tromey at redhat dot com changed: What|Removed |Added CC||tromey at redhat dot com --- Comment #1 from Tom Tromey tromey at redhat dot com --- This looks like: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332 ... which was fixed a while ago. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16218] New: readelf -wi prints trailing whitespace
https://sourceware.org/bugzilla/show_bug.cgi?id=16218 Bug ID: 16218 Summary: readelf -wi prints trailing whitespace Product: binutils Version: unspecified Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tromey at redhat dot com I noticed that readelf -wi will print trailing whitespace after a DW_AT_name. In particular it seems to print a trailing TAB character. I don't see any reason for this, and it makes searching the output a bit more difficult than it needs to be. You can see it easily with: ./readelf -wi ./readelf |grep '$' (where there is a literal tab in those quotes) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
https://sourceware.org/bugzilla/show_bug.cgi?id=14768 Tom Tromey tromey at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Tom Tromey tromey at redhat dot com --- Whew. I hope. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
https://sourceware.org/bugzilla/show_bug.cgi?id=14768 Tom Tromey tromey at redhat dot com changed: What|Removed |Added Assignee|fred.cooke+nospam at gmail dot com |tromey at redhat dot com --- Comment #22 from Tom Tromey tromey at redhat dot com --- Doing it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #14 from Tom Tromey tromey at redhat dot com --- (In reply to Alan Modra from comment #11) Can I suggest a commit log policy change when we switch to git? In my proposal I ask that these things be considered separately. I'm in favor of many process changes, including this one, but I want to focus on just the conversion, which is pretty complicated by itself. FWIW many gdbers have already switched to git-style commits in the CVS repository. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #15 from Tom Tromey tromey at redhat dot com --- (In reply to Ian Lance Taylor from comment #13) My CVS stitching process is not so mysterious, it's in the CVS repository :ext:sourceware.org:/cvs/sourceware/coolo-cvs on the gccmerge branch. The main command is in src/gccmerge.c. A few constants in that file would have to be changed for the binutils code. But if git has a stitching process, no reason not to use that. Thanks, Ian. The cvs approach may be easier in practice for this, though I still haven't fully researched the git approaches. I'd like to get a copy of the old CVS repository. Can you put it up for ftp somewhere? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #7 from Tom Tromey tromey at redhat dot com --- Joseph pointed out that we want to stitch in the pre-sourceware CVS history, which is available: http://sourceware.org/ml/binutils/2012-10/msg00407.html There are a few candidates for merging this in: 1. Whatever mysterious process Ian refers to in that email; 2. reposurgeon 3. git stitch-repo 4. git grafts plus git filter-branch -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #9 from Tom Tromey tromey at redhat dot com --- (In reply to Fred from comment #8) About the last comment, though: Anything that disrupts current Git users should probably be avoided. Get it into Git, sure, but why not just leave it on a branch called pre-sourceware or similar? We're making a new gdb+binutils repository, for reasons outlined in the various threads -- so current users will already be inconvenienced. Note that the inconvenience is pretty small. An existing branch can be migrated quite easily via git am, just by finding the corresponding branch point. There are probably other ways as well. This should have been done up front really. The history wasn't publicly available when the mirror was created. If it's being done now, everyone should be notified heavily before the existing history is smashed/re-hashed and anyone down stream is broken by it. We won't overwrite gdb.git or binutils.git. We'll have a new src.git and mirroring to the existing it repositories will be disabled. Current users will pay a small one-time transition cost. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #5 from Tom Tromey tromey at redhat dot com --- * examine gdb and binutils documentation to see what needs to be updated. This means looking at the texinfo manuals, the web sites, and the gdb wiki. I've done this locally. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #6 from Tom Tromey tromey at redhat dot com --- I forgot a to-do item: * Disable the current cvs-git importers Also there is the question of what to call the resulting repository. This affects at least the documentation. I'm using src.git for now, but it can be discussed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #4 from Tom Tromey tromey at redhat dot com --- * make src-release ignore .git (trivial) see the CVS_NAMES variable Testing reveals that we don't need this. * update the gdbadmin scripts I've done this but have not tested them. * port log_accum_bugzillafied to git I've done this. I've partially tested it (I tested the post-receive script modifications). See also bug #13746. * likewise, set up git commit email This is really part of the previous task. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 --- Comment #3 from Tom Tromey tromey at redhat dot com --- It would be helpful to collect a list of concrete tasks to be done. I'm assuming, per the threads, that a shared gdb+binutils repository would be created. * make src-release ignore .git (trivial) see the CVS_NAMES variable * update the gdbadmin scripts * update the BFD daily date-updating commit * port log_accum_bugzillafied to git * likewise, set up git commit email * update DJ's script that auto-merges top-level changes from GCC * examine gdb and binutils documentation to see what needs to be updated. This means looking at the texinfo manuals, the web sites, and the gdb wiki. Is there anything I've missed? Once the conversion is in place we can add: * mark the various converted directories as read-only in CVS -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15545] New: BFD cache loses cloexec flag
http://sourceware.org/bugzilla/show_bug.cgi?id=15545 Bug ID: 15545 Summary: BFD cache loses cloexec flag Product: binutils Version: unspecified Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tromey at redhat dot com Created attachment 7047 -- http://sourceware.org/bugzilla/attachment.cgi?id=7047action=edit test program Consider the attached program. (Compile it and run it on itself to see the error.) It opens a BFD using an explicit fd. Then it calls bfd_cache_close_all. Despite the comment in opncls.c: /* If we opened the file by name, mark it cacheable; we can close it and reopen it later. However, if a file descriptor was provided, then it may have been opened with special flags that make it unsafe to close and reopen the file. */ if (fd == -1) (void) bfd_set_cacheable (nbfd, TRUE); ... this causes the fd to be closed. The BFD is not marked cacheable but bfd_cache_close_all ignores this flag. Then, the test program forces the BFD to be reopened. Now, the cacheable flag is set. All this is more subtle than it appears because I think GDB relies on bfd_cache_close_all actually closing such fds. One idea would be to simply remove the calls to bfd_cache_init from opncls.c, but at the same time change gdb to add them. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15545] BFD cache modifies cacheable flag
http://sourceware.org/bugzilla/show_bug.cgi?id=15545 Tom Tromey tromey at redhat dot com changed: What|Removed |Added Summary|BFD cache loses cloexec |BFD cache modifies |flag|cacheable flag -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15546] New: real_fopen does not set CLOEXEC in thread-safe way
http://sourceware.org/bugzilla/show_bug.cgi?id=15546 Bug ID: 15546 Summary: real_fopen does not set CLOEXEC in thread-safe way Product: binutils Version: unspecified Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tromey at redhat dot com Right now, bfdio.c:real_fopen sets the CLOEXEC flag on any files it opens. Howevere, there is a window between opening the file and setting this flag, during which another thread could fork and exec. The best fix would be to use O_CLOEXEC, or the fopen e modifier, on platforms that support it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15356] New: BFD's decompress_contents can maybe leak memory
http://sourceware.org/bugzilla/show_bug.cgi?id=15356 Bug #: 15356 Summary: BFD's decompress_contents can maybe leak memory Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: tro...@redhat.com Classification: Unclassified BFD's compress.c:decompress_contents has a couple of return paths that do not call inflateReset. I think this can leak memory. A simple fix seems to be replacing return FALSE with break in both places it appears in the loop; or alternatively calling inflateEnd before each return. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15152] New: readelf and objdump don't print strings from .dwz file
http://sourceware.org/bugzilla/show_bug.cgi?id=15152 Bug #: 15152 Summary: readelf and objdump don't print strings from .dwz file Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: tro...@redhat.com Classification: Unclassified If you process an executable with dwz, it may rewrite the DWARF to reference strings in the new .dwz file. Neither readelf nor objdump will actually show the content of these strings. For example: objdump --dwarf=info ./gdb.cp/anon-struct [...] 0b: Abbrev Number: 1 (DW_TAG_compile_unit) c DW_AT_producer: (alt indirect string, offset: 0xb9) 10 DW_AT_language: 4(C++) 11 DW_AT_name: (alt indirect string, offset: 0x44) 15 DW_AT_comp_dir: (alt indirect string, offset: 0x85) Showing the strings would be very helpful. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14768] Checklist: Binutils Migration To Git
http://sourceware.org/bugzilla/show_bug.cgi?id=14768 Tom Tromey tromey at redhat dot com changed: What|Removed |Added CC||tromey at redhat dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14736] New: probable bug in elf32-microblaze.c:microblaze_elf_relax_section
http://sourceware.org/bugzilla/show_bug.cgi?id=14736 Bug #: 14736 Summary: probable bug in elf32-microblaze.c:microblaze_elf_relax_section Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: tro...@redhat.com Classification: Unclassified I happened to build bfd with clang and it found this: ../../archer/bfd/elf32-microblaze.c:1744:21: warning: use of unary operator that may be intended as compound assignment (-=) isym-st_value =- calc_fixup (isym-st_value, sec); ^~ Based on other uses of calc_fixup, I think clang is correct and this should be -= instead. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14475] strip is broken on archive
http://sourceware.org/bugzilla/show_bug.cgi?id=14475 Tom Tromey tromey at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Tom Tromey tromey at redhat dot com 2012-08-16 14:26:33 UTC --- Fixed. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14481] New: bfd leaks archive member hash table
http://sourceware.org/bugzilla/show_bug.cgi?id=14481 Bug #: 14481 Summary: bfd leaks archive member hash table Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: tro...@redhat.com Classification: Unclassified Created attachment 6583 -- http://sourceware.org/bugzilla/attachment.cgi?id=6583 test program BFD makes a hash table for archive members, but then leaks it. See http://sourceware.org/ml/binutils/2012-07/msg00162.html You can see the leak under valgrind using this program. Be sure to run it on a normal archive, a thin archive, and a thin archive that contains another archive. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14482] New: closing an archive member will invalidate archive cache
http://sourceware.org/bugzilla/show_bug.cgi?id=14482 Bug #: 14482 Summary: closing an archive member will invalidate archive cache Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: tro...@redhat.com Classification: Unclassified If you close a BFD coming from an archive, the archive member hash will not be notified, leading to a stale pointer. See http://sourceware.org/ml/binutils/2012-07/msg00162.html You can see this using the test program in PR 14481 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14475] strip is broken on archive
http://sourceware.org/bugzilla/show_bug.cgi?id=14475 --- Comment #3 from Tom Tromey tromey at redhat dot com 2012-08-15 20:57:30 UTC --- I think the bug is that bfd_ar_hdr_from_filesystem allocates the areltdata on the wrong BFD. I'm testing a patch. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/14475] strip is broken on archive
http://sourceware.org/bugzilla/show_bug.cgi?id=14475 --- Comment #4 from Tom Tromey tromey at redhat dot com 2012-08-15 21:00:51 UTC --- (In reply to comment #2) Since if (!bfd_close (obfd)) closed all output bfds now, bfd_close (l-obfd) closes a closed bfd. No, that isn't it. The member BFDs are only closed for an archive opened for reading. I'll send my patch in a minute. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
