[Bug binutils/11983] libbfd reuses pointer passed to bfd_openr
http://sourceware.org/bugzilla/show_bug.cgi?id=11983 --- Comment #11 from Nick Clifton --- 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. > 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. I ran as many checks as I could and visually inspected all of the code. I think that I found everywhere that the filename is touched. At least inside the binutils that is. Cheers Nick -- 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
Re: Objcopy to convert binary file to object file for Cortex-M4
Hi Steve, We would like to help you but... > CONFIDENTIALITY STATEMENT. This email and any attachment is for the > sole use of the intended recipient and may contain private, > confidential and/or privileged information that may be subject to > Hospira internal policies. If you are not the intended recipient, any > dissemination, distribution or copying is strictly prohibited. If you > have received this transmission in error, please notify Hospira > immediately by return email or by email to > privacypostmas...@hospira.com and delete the message and all copies > and attachments from your system. Unfortunately we cannot respect this confidentiality statement. Neither can we delete the email from our system. This is a public email list, open to all. If you do want to post a question to this list, please do so without any confidentiality requirements. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/16199] Objcopy crash when section alignment is zero
http://sourceware.org/bugzilla/show_bug.cgi?id=16199 --- Comment #2 from cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via dc9155b24f8d8ea5ecb1af433d12280433b216ce (commit) from 8cc4c22675eaac5dabc1f4ffeb396688d1ae3b91 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dc9155b24f8d8ea5ecb1af433d12280433b216ce commit dc9155b24f8d8ea5ecb1af433d12280433b216ce Author: Nick Clifton Date: Fri Jan 3 14:16:17 2014 + PR binutils/16199 * elf.c (vma_page_aligned_bias): Handle a maxpagesize value of zero. --- Summary of changes: bfd/ChangeLog |6 ++ bfd/elf.c |5 - 2 files changed, 10 insertions(+), 1 deletions(-) -- 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/16199] Objcopy crash when section alignment is zero
https://sourceware.org/bugzilla/show_bug.cgi?id=16199 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Hi Joshua, Thanks for the bug report and patch. I decided that it would be better to patch the vma_page_aligned_bias function, in case it is ever called from other locations with an alignment of zero. Cheers Nick -- 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/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 7337 --> https://sourceware.org/bugzilla/attachment.cgi?id=7337&action=edit Proposed patch -- 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/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
https://sourceware.org/bugzilla/show_bug.cgi?id=16202 Nick Clifton changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Nick Clifton --- Hi Ma, I do not think that refetching the addend in the ABS8 and ABS16 cases is the right thing to do. There could be other relocations that are affected by the same problem. Instead I think that the correct thing to do is to fetch the addend using the proper bfd_get_XX macro in the first place. 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Objcopy to convert binary file to object file for Cortex-M4
All, Sorry for my previous email blunder ... obviously I don't post to public forums often :). My question (in the clear) is if there is an existing means to perform the binary to ARM EABI 5 object file conversion or whether this support is just missing from the current set of utilities? I’m trying to use the objcopy utility for ARM to convert a binary file into an object file to be linked into a system build and I’m running into an issue that I hope someone can help with. The issue is that the resulting object file is in the ARM EABI 0 format instead of the ARM EABI 5 format required by the linking process. Some details: - The tool chain used is built for RTEMS similar to http://www.rtems.org/wiki/index.php/Building_Tools - The version of binutils used is 2.24 - The target microcontroller is a Cortex-M4, thus it uses the “armv7-m” architecture and as I understand it must use the EABI 5 format The command used to convert the binary file to an object file is: arm-rtems4.11-objcopy –I binary –B arm –O elf32-littlearm .bin .o This operation appears to work in that the .o file is created. When the linker attempts to build the elf file I receive the following error: ld: error: Source object .o has EABI version 0, but target .elf has EABI version 5 The linker is actually called via a call to “arm-rtems4.11-g++” with numerous options and *.o files and such. The only significant options I see that are related to this issue are “-march=armv7-m –mthumb”. I’ve tried a number of different approaches but haven’t hit on a winning combination. FYI, we used this same sort of binary to object conversion (via objcopy) on a prior non-ARM architecture and it worked fine. Regards, Steve. ___ 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 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat dot com -- 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 #12 from Tom Tromey --- (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
