Re: linker seg fault
On Tue, Jun 28, 2005 at 12:00:41PM +0100, Will Wagner wrote: > We are using ld version 2.14. I have attached a simple test case that > exhibits the error. I'm guessing that there is some error with the > options I'm passing to gcc, but ld just falling over doesn't make > debugging easy. > > Can anyone suggest why it is falling over. It is unlikely that anyone can help you with binutils 2.14 now; could you try a current version, i.e. 2.16.1? -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld: BFD 2.15.92.0.2 20040927 internal error, aborting at ../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section
On Fri, Jul 15, 2005 at 03:39:50PM -0400, David Lawless wrote: > Is this the correct approach? Or am I missing some important > detail, such as not making certain symbols LOCAL? Or am I > on entirely the wrong path for obtain my objective? Local symbols are not accessible from outside of the file in which they are defined, so converting all the symbols to local is definitely not what you want. Maybe converting them to hidden. -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: binutils 2.16.1 assembler dwarf2 relocations break solaris native ld
On Fri, Aug 12, 2005 at 04:28:12PM +0200, Eric Botcazou wrote: > > So who is right here? Is there really an alignment problem with the > > debug sections in the object file, or is the solaris linker just > > confused? If there is a problem, why doesn't binutils ld complain? > > GNU ld supports unaligned R_SPARC_32 relocations, while Sun ld doesn't. The > relocations should have been R_SPARC_UA32 for Sun ld to be able to grok > them. The bottom line is that you need GNU ld if you want to directly > use -gdwarf2 with GNU as (or use -g on an assembly file with GCC). Silly question, perhaps, but why not have gas generate R_SPARC_UA32? -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1343] New: need --with-lib-path = $exec_prefix for ld
On Wed, Sep 14, 2005 at 03:29:45PM -, russfink at hotmail dot com wrote: > I compiled a binutils for a custom target, and specified "./configure > --prefix=foo --exec_prefix=arch/foo" at the top level binutils directory. > During the build, it went into the "ld" directory and did a standard > "./configure". The option is --exec-prefix, not --exec_prefix. > This can be done easily because ld's configure has a --with-lib-path option - > but the toplevel binutils does not have any matching option nor does it > propagate any such thing down. The toplevel configure script propogates unknown --with options to all subdirectories. Have you tried using --with-lib-path? -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Is this a bug? Can do mov r0, #676
On Sat, Oct 01, 2005 at 11:27:38AM -0500, Jay Monkman wrote: > I'm using a cross assembler for ARM, running on x86, and seeing something > weird. > > Here's the test program: > > foo: > mov r0, #675 > > Assemble with this: > arm-linux-as -o foo.o foo.S > > Here's what happens: > arm-linux-as -o foo.o foo.s > foo.s: Assembler messages: > foo.s:0: Warning: end of file not at end of a line; newline inserted > foo.s:2: Error: invalid constant -- `mov r7,#675' > > If the number is 676 it works fine. > > I've tried with the following binutils versions with identical results. > 2.13.2.1 > 2.15. > 2.16.1 > > Immediate operands are limited to 8 bits. Then why does 676 work? You should take another look at the ARM instruction set documentation; immediate moves are limited to eight bits _plus a rotate_. -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in obje ct file in 64bit world
On Fri, Nov 04, 2005 at 04:04:05PM +0100, Mlynarik Jan wrote: > Hello, > > We are using a cross compiler for 64 bit Linux on MIPS yosemite. When we > compile c sources with command: > > mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=64 example2.c > > then the values of DW_AT_high_pc and DW_AT_low_pc atributes in dwarf2 info > are 0, what is surely wrong. > > If we use "mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=32" then there are > reasonable values in these attributes. > > This is not a problem of the dwarfdump, because this values can be found > also by hand in the object files. I don't know why it works for 32-bit and not for 64-bit. Readelf output would be more useful for that question. However, in general you can not use dwarfdump or readelf to look at unrelocated object files, only linked ones. If you use readelf -r, you will see relocations associated with the dwarf sections, at the offsets of the "bad" DW_AT_high_pc fields. This is not a bug. -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld doesn't warn about undefined symbols
On Wed, Nov 02, 2005 at 06:01:03PM +0100, Jakub Jermar wrote: > ld (from binutils 2.16) on mipsel doesn't warn about > undefined symbols with elf32-little and binary output > formats (and possibly others). > > When the output format is elf32-tradlittlemips, undefined > symbols are reported as expected. > My project needs to use both binary and elf32-little > targets, so it is essential for me to know what is going on. No, you don't need to use either. I strongly recommend you always let the linker target a format that it knows about, and use objcopy to convert to any other formats you want to generate. > boot.bin: boot.o test.o > $(LD) $(LFLAGS) boot.o test.o -o $@ > OUTPUT_FORMAT(elf32-little) > /*OUTPUT_FORMAT(binary)*/ $(LD) $(LFLAGS) boot.o test.o -o [EMAIL PROTECTED] $(OBJCOPY) -O binary [EMAIL PROTECTED] $@ -- Daniel Jacobowitz CodeSourcery, LLC ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Building binutils-2.15.97 --enable-targets=all
On Mon, Jan 30, 2006 at 03:54:10PM +0200, Muhammad Haggag wrote: > On 1/30/06, Nick Clifton <[EMAIL PROTECTED]> wrote: > > Hi Muhammad, > > > > > While building binutils (binutils-2.15.97.tar.bz2) on Cygwin, as follows: > > >> configure --enable-targets=all --enable-shared --with-gnu-as > > >> --with-gnu-ld > > >> make > > > > > I got the following error: > > >> obj-coff.o: In function `coff_frob_symbol': > > >> /usr/src/binutils-2.15.97/gas/config/obj-coff.c:1145: undefined > > > reference to `_an_external_name' > > > > This does not happen with the latest sources in the CVS repository, nor > > with the officially released 2.16 sources, so I do not really see this > > as a problem. > > > Hmm...I downloaded 2.15.97 because it was the latest on > ftp://sourceware.org/pub/binutils/snapshots - didn't know there was a > more recent release. binutils-060130.tar.bz2 is more recent; the things with 2.x.y version numbers are prerelease snapshots, and the matching final releases are available in the releases directory. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objcopy --add-section doubt
On Mon, Jan 30, 2006 at 01:13:32PM +, Nick Clifton wrote: > Yes - this is the heart of the matter. What is happening is that you > are attempting to add a section that already exists. The old (RH9) > binutils silently allowed this, which was incorrect. Wait... why? There's no restriction in ELF about having multiple sections with the same name; some non-GNU tools do this a lot. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld error: internal error, aborting at ../../bfd/cache.c line 495 in bfd_cache_lookup_worker
On Mon, Jan 30, 2006 at 01:09:56AM +1100, John Pye wrote: > > /usr/bin/ld: BFD 2.15.94.0.2.2 20041220 internal error, aborting at > > ../../bfd/cache.c line 495 in bfd_cache_lookup_worker > > > > /usr/bin/ld: Please report this bug. FYI, this abort is no longer present in current versions. It used to mean that a file could not be reopened, e.g. had been deleted while the linker was using it. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
On Wed, Mar 08, 2006 at 10:19:56AM +, Nick Clifton wrote: > *** main (int argc, char ** argv) > *** 1205,1211 > keep_it = 0; > > if (!keep_it) > ! unlink_if_ordinary (out_file_name); > > input_scrub_end (); > > --- 1206,1212 > keep_it = 0; > > if (!keep_it) > ! unlink (out_file_name); > > input_scrub_end (); > Is this bit unrelated? -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
On Fri, Mar 10, 2006 at 08:40:18PM -0500, George M. Gallant, Jr. wrote: > Daniel, > > I don't understand the context of you question. The patch from Nick > seems to > fix my concern. Right - it was directed at Nick. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: x86_64 target for Solaris 2.10?
On Mon, Jul 24, 2006 at 09:36:50AM -0400, Tucker Taft wrote: > I am trying to build a gdb (6.3) for the x86_64 host/target > for Solaris 2.10. BFD does not seem to support > x86_64 for Solaris. Is there a different target I could > use to configure bfd which would also work on solaris? Try i686-pc-solaris2.10, using GDB 6.5. But I don't think GDB supports 64-bit binaries on Solaris x86. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: binutils doc on www.gnu.org
On Sun, Nov 26, 2006 at 11:29:54AM -0600, Karl Berry wrote: > Greetings, > > Hans-Peter (cc'd) suggested to the GNU webmasters that the binutils doc > on http://www.gnu.org/software/binutils be kept to date, and also that > information about this would be useful. So here it is. If irrelevant > to you, please ignore, and sorry to bother. H-P, which doc, specifically? There isn't a copy of the manual there; it only links to the copy on sourceware. I have write access to that page and I keep its link up to date. Or, did you mean adding a copy there so that one didn't have to go to sourceware? -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: arm-elf-as 2.16.1 always gives "relocation truncated to fit: R_ARM_PC24"
On Tue, Feb 06, 2007 at 04:04:02PM -0800, Bryce Schober wrote: > Not sure if this is true on latest binutils, but arm-elf-as 2.16.1 always > gives: I doubt that error is coming from the same place. Please file a bug report with a complete assemblable and linkable testcase that shows the error, including command lines. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: More: binutils-2.17 build tries to modify distribution directory
On Thu, Apr 19, 2007 at 03:21:42PM +0200, [EMAIL PROTECTED] wrote: > > Hi again > Regarding modifying the dist.directory, my "Not so bad, the build proceeds > alright" > below was optimistic. When the dist. directory is totally read-only (such as > on > a read-only disk, or wich "chmod -R go-w binutils-2.17"), the build fails at > the > step shown below. What is the point of building in a different directory, if > the > original directory still needs to be modified? It was a bug - very hard to fix, because it came from Automake, not from binutils. It will be fixed in the next release, or you can get a snapshot. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: shared lib relocation problem
On Thu, Sep 20, 2007 at 09:57:23PM +0200, Jozef Kruger wrote: > Since the system and host modules are compiled into shared libraries > I would expect that they end up calling the print function defined > in their own module (since those references have been resolved > already, both shared objects contain no undefined reference to > "print"). No. All dynamic references to a function named print will resolve to one copy. If you linked the application with -rdynamic, it would be that copy. You can get the results you expect by using a linker script, or GCC's __attribute__((hidden)) or -fvisibility=hidden. This is a difference between ELF linkage and Windows-style DLL linkage. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Correct ELF machine for coldfire?
On Thu, Jan 31, 2008 at 02:32:46PM +, Nick Clifton wrote: > Hi Jonathan, > >> We are compiling for Coldfire CFV4E target. Binutils seems to want to >> set the ELF header em_machine field to EM_68K with about half a dozen >> options set to indicate instruction set and so forth. >> >> Should this be getting set to EM_COLDFIRE, or is the existing behavior >> correct? > > I think that it is a bug. ie the number should be EM_COLDFIRE. The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools do. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: localization of binutils to Hungarian
On Mon, Apr 28, 2008 at 09:20:45PM +0200, Németh Márton wrote: > Hi, > > I crated a localization of binutils to Hungarian two years ago. Now I found > this file again, and I send it, I hope it will be useful for someone. The > localization was made for version 2.16.1. If you send this to the GNU Translation Project robot, it will automatically be picked up for binutils once it's included. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: localization of binutils to Hungarian
On Tue, Apr 29, 2008 at 04:27:05PM +0200, Németh Márton wrote: > Where can I reach the GNU Translation Project robot? > > Is there any documentation about this robot? It's the first google result for "gnu translation project": translationproject.org. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Build error with binutils 2.18: requires makeinfo but shouldn't
On Tue, Jun 17, 2008 at 10:39:57PM -0400, Paul Smith wrote: > The first problem is that the bfd/elf.c file is much newer (like, 3 > weeks newer) than most of the rest of the bfd directory, and in > particular much newer than the bfd/doc/elf.texi file. If the > distribution was created as it should be, from a pristine checkout of > the CVS tree, this wouldn't be the case since the bfd/doc/elf.texi file > would be constructed from bfd/elf.c with the "chew" utility, and thus > the .texi would be newer, so make would not try to rebuild elf.texi and > then would not decide it needed makeinfo to rebuild bfd.info. All I can > surmise is that the distributed package was built from a checked out > workspace that had already been used for other builds before; in that > case the move-if-changed script would not have updated the > bfd/doc/elf.texi file if the changes to elf.c didn't result in updates > to elf.texi. The release branch has the generated files in it. This is how binutils releases have traditionally been managed. It's the snapshots before the final release that cause this problem. The most practical solution is to touch the generated files during tarball building, or be sure to remove them before starting the release process, even though we check them in again afterwards. src-release can be enhanced. > elf.texi: chew.c $(srcdir)/../elf.c $(srcdir)/doc.str > $(MAKE) $(MKDOC) > ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elf.c >elf.tmp > $(SHELL) $(srcdir)/../../move-if-change elf.tmp elf.texi > > Although this rule SEEMS to do things correctly, using $(srcdir) etc., > it falls down at the last step. In that step we pass elf.tmp and > elf.texi to move-if-change, but that's not correct because if we are > building outside the source tree, "elf.texi" does not exist! That file > lives in the $(srcdir). Because it does not exist, move-if-change > always moves it, of course, and thus it is newer than bfd.info and thus > we always need makeinfo to build binutils. > > I think this code needs to be smarter, and first make a copy of the > $(srcdir) version of elf.texi preserving timestamps, then do the > move-if-change. It may be necessary to discuss this with the folks on > the autoconf lists, to be sure the correct behavior is preserved. To the best of my knowledge there is no portable way to do this. If someone else wants to work on it... -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Build error with binutils 2.18: requires makeinfo but shouldn't
On Mon, Jun 23, 2008 at 02:19:36PM -0400, Paul Smith wrote: > On Sat, 2008-06-21 at 11:59 -0400, Daniel Jacobowitz wrote: > > The release branch has the generated files in it. This is how > > binutils releases have traditionally been managed. It's the snapshots > > before the final release that cause this problem. > > Hi Daniel; > > I don't think this is true, at least not in this situation. Before I > posted the bug I checked cvsweb and there is no "elf.texi" file checked > into the bfd/doc directory in CVS, either on the trunk or on the > binutils-2-18 branch. For 2.18, it's revision 1.1.18.1 of elf.texi. I had to go into the Attic to find it. Cvsweb does not appear to do The Right Thing for files that do not exist on trunk. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Build error with binutils 2.18: requires makeinfo but shouldn't
On Mon, Jun 23, 2008 at 06:51:22PM -0400, Paul Smith wrote: > Still and all, it's something that would be great to have fixed in the > official release distributions; if for no other reason than it would > save you guys a lot of bug reports about problems with makeinfo (in > researching this bug I saw quite a number of these). Oh, agreed... I'm thinking about the best solution. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Conflict between MIPS PLTS and abicalls stubs
On Wed, Mar 25, 2009 at 10:46:26PM -0400, Colin Burgess wrote: > BTW - I'm not sure of the protocol - should this have been sent via the > development list or entered into bugzilla? Either of those - but sending mail to the bugs list is the worst of both worlds; fewer people read that list and it isn't tracked in the database. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
