Re: ./install-sh
"Lyngmo Ted" <[EMAIL PROTECTED]> writes: > I just downloaded > http://ftp.gnu.org/gnu/binutils/binutils-2.15.tar.gz > and compiled it. > > When I then did "make install", it couldn't find "./install-sh" in any of the > subdirectories. > I hardlinked the top level "install-sh" in every subdirectory and then tried > "make install" again. This time it worked. Thanks for the bug report. This bug has been fixed for the next release. Most people run configure in a different directory, rather than running ./configure. That works correctly in binutils 2.15. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld fails to link if library order is reversed
Nilmoni Deb <[EMAIL PROTECTED]> writes: > Lets say I am running the following command > > gcc z.o -lX -lY -o z > > and libX.a depends on a function that is defined in libY.a then the order > of linking appears to be important. While the previous command works, the > next one (with order reversed) will fail: > > gcc z.o -lY -lX -o z > > This problem has been observed with binutils version 2.10.91. I would > think that ld should look back when resolving dependencies. This is correct and documented behaviour. All Unix linkers behave this way. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld fails to link if library order is reversed
Nilmoni Deb <[EMAIL PROTECTED]> writes: > > This is correct and documented behaviour. All Unix linkers behave > > this way. > > In other words, its a feature, not a bug. It seems that the ICC (intel > cc) on linux does not have this feature. Really? I haven't tried it myself. > Just wondering why not looking backwards (for ld) is considered desirable. 1) It's traditional Unix behaviour, so changing it will break some programs. 2) It is more efficient, as the linker can just walk through an archive's symbol table, include all required objects, and then move on. You may want to look at the --start-group --end-group options. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld fails to link if library order is reversed
Nilmoni Deb <[EMAIL PROTECTED]> writes: > > 1) It's traditional Unix behaviour, so changing it will break some > >programs. > > Any example ? I don't have any specific examples, no. > > 2) It is more efficient, as the linker can just walk through an > >archive's symbol table, include all required objects, and then move > >on. > > In other words, save an average of half the time by not looking back. Not that it really matters, but I think the analysis is a little more complicated than that. You would have to keep a separate hash table for identifiers found in an archive symbol table but not included in the link yet, and then you would have to do another hash lookup for each new undefined symbol. Or you would have to make the regular hash table much larger, and annotate symbols in there for 'defined but not included in link', but that would slow down every hash table lookup on average. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, I need to run objdump under windows XP to dump out XCOFF format object > files > created from IBM AIX environment, is that possible? I went to gnu.org site, > and do not see where I can download the gnu package containing the objdump > command, anybody could help me with this? Yes, it is possible, but it is not particularly easy if you are not familiar with this kind of thing. If you have not done so already, you will need to download cygwin--see http://cygwin.com/ That will give you an objdump, but one that only supports PE COFF. You will need to build your own version of the binutils for the rs6000-aix target. You can do this using cygwin. Download the binutils sources from, and follow the directions. http://sourceware.org/binutils/ Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks for your response, I already downloaded both cygwin and > binutils, I used objdump of cygwin to dump out ELF format object files for > my current project under windows XP, now my project needs to support XCOFF > object file dumping in XP environment, the binutils I downloaded seems not > for windows XP environment when I looked at the files I untarred, is there > any MS windows version of binutils? how can I build my own version of the > binutils for rs6000-aix target? I checked the binutils source code, it seems > supporting rs6000-aix target already. In the binutils source code see binutils/README for how to build. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks for your response again, I checked the binutils/README, it > talks about how to build for unix-like system, not for windows XP > environment, for example, it asks to do ./configure command, which in the > binutils directory is not a DOS or windows command, when I run the commands, > they just did not work, the version of binutils I downloaded is > binutils-2.15, I am not sure what I should do. Would you please help me with > this issue again? Downloading cygwin from http://cygwin.com/ will give you a Unix-like environment on Windows. It is sufficient to build the binutils. You should run configure from the cygwin shell. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, I got what you mean with cygwin, I just built the binutils with the > help of cygwin, but unfortunately the objdump.exe command donot support > xcoff format when I run objdump -i, it will list all the supported format, I > checked the objdump.c source code, it never has any information about xcoff, > but in other source code like xcoff.h, it has some xcoff information, I > donot know what I need to configure to support xcoff format. any idea? configure with --target rs6000-ibm-aix Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks again for your help, I tried to configure > with --target=rs6000-ibm-aix, and built the binutils, when I tested the > objdump.exe file with objdump -i, it gave me error: "objdump: can't set BFD > default target to 'rs6000-ibm-aix': Invalid bfd target", I tried to > configure with --target=rs6000-aix as described in readme, it gave me the > same error message, after that I tried to configure > with --enable-targets=all, then tested with objdump -i, it gave me all the > supported things like pe-i386, elf32-i386 etc, but no rs6000-aix, any idea > or what have I done wrong? Hmmm, maybe you need --target=powerpc-aix these days. Or even --target=powerpc-elf should give you an objdump which can read XCOFF files. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i, > they gave me error saying "objdump: can't set BFD default target to > powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target > to powerpc-unknown-elf: Invalid bfd target"; any other idea? No, I don't know offhand what is going on there. Sorry. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: opcodes-2.15.vi clarification
Clytie Siddall <[EMAIL PROTECTED]> writes: > > IC:%s [%s] has no terminals or sub-classes\n > > "terminals" in this case, I am assuming, don't mean VDU installations > or command-line windows. Would I be correct in translating this to > mean "terminal variables"? I am unsure. Please dispel a little of the > fog in which I am struggling. :) This means terminals in the technical sense. It means something like "an item which has been full expanded". The word is often used in the context of parsing; perhaps you can find other examples if you can look at a Vietnamese compiler text. > > no insns mapped directly to terminal IC %s [%s] > > Does "terminal" here have the same meaning as in #1? Is it an > adjective applying to "IC", or a noun in its own right? I need to > know, because adjectives follow the noun in Vietnamese: "terminal IC" > (if the terminal is describing the IC) would be "IC terminal". I don't > want to split up the end of the string, however, if it is all part of > a complex variable... Terminal can be either an adjective or a noun. Here it is an adjective. (You do know that these are just debugging messages, right? No normal user will ever see them.) > > Warning: rsrc %s (%s) has no chks%s\n > > I am assuming "resource" for "rsrc", and think "chks" is probably > "checks": is that correct? "resource" is correct. "checks" is the English word here; it is used in the sense of "prevents." > > rsrc %s (%s) has no regs\n > > "regs": registers? ? Yes, although it really means a resource which is used by this instruction. > > opcode %s has no class (ops %d %d %d)\n > > "ops": operands? operators? operations? Operands. > > parse_addr16: invalid opindex. > > "opindex": an index of (again) operands? operators? operations? An index into the list of operand types, in this case. > > \n > > "opcode": op? as above (I hope they're not all different, but just in > case, I'm enquiring for each case of "op" here. If there is only one > meaning for that abbreviation throughout, please just say so. :) Here it is opcode, not operand. > > # > > disassembly/disassembler? Yes. This is printed for an instruction which could not be disassembled. > > Bad case %d (%s) in %s:%d\n > > "case" as in "upper/lower case", or "case" as in "situation, example"? The latter. > > index register in load range > > "index" as in "root, base" or "index" as in "table"? The latter, I suppose. An index register is a register used in a memory address with an optional scaling factor. It gets the name from "array index", because that is a common use. That said, I suspect that this particular error message should use "base register" instead. > > unknown operand shift: %x\n > > "shift" as in "change"? Shift as in left shift or right shift of a number. > > unknown pop reg: %d\n > > "pop reg" as in "population register"? No, this is a register which appears in a stack pop instruction. > > No relocation for small immediate > > "immediate number" or "immediate expression"? An immediate number in an instruction. Most, perhaps all, of these messages are debugging messages or error messages for cases which are supposed to be impossible. They are not messages which will ever be seen in any normal circumstances. It's not clear to me that these strings should be marked for translation. Thanks for doing this, though. > In future, in order to obviate this process with later files, or at > least make it easier :) I'd encourage you to include a contact > address in the Report-Msgid-Bugs-to field, and to use the Developer > Comments field for each string to explain meanings, to make sure what > you mean is actually transmitted in the localized version. Thanks for the suggestions. I agree that there ought to be something in the Report-Msgid-Bugs-to field, although I don't myself know how to set it. I just see it in opcodes.pot, which is a generated file. Wishing for better Developer Comments for these cases is, I think, hopeless. The messages aren't really comprehensible in English, either, except to a developer. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system
"David Du" <[EMAIL PROTECTED]> writes: > Hi, anybody can answer this question: objdump not working for IBM AIX xcoff > object file? Why don't you open a PR at http://sourceware.org/bugzilla/ so that we don't lose track of this? Thanks. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Problem with linking ununsed symbols in a shared library
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > gcc -I. -c main.c test1.c test2.c > gcc -shared -o libtest1.so test1.o > gcc -shared -o libtest2.so test2.o > gcc -o test -L. -ltest1 main.o > > $ ./compile.sh > ./libtest1.so: undefined reference to `func4' > collect2: ld returned 1 exit status func4 is defined in libtest2.so. You aren't linking against libtest2.so. This is expected behaviour. Why would you expect something different? Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Problem with linking ununsed symbols in a shared library
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > On Tuesday 05 Apr 2005 1:17 am, Ian Lance Taylor wrote: > > Shridhar Daithankar <[EMAIL PROTECTED]> writes: > > > gcc -I. -c main.c test1.c test2.c > > > gcc -shared -o libtest1.so test1.o > > > gcc -shared -o libtest2.so test2.o > > > gcc -o test -L. -ltest1 main.o > > > > > > $ ./compile.sh > > > ./libtest1.so: undefined reference to `func4' > > > collect2: ld returned 1 exit status > > > > func4 is defined in libtest2.so. You aren't linking against > > libtest2.so. This is expected behaviour. Why would you expect > > something different? > > The main.c does not have any reference to func4. main.c uses just func1 which > is available in libtest1.so and does not use any function in libtest2.so. So > libtest2.so should not be required at all. The linker doesn't know that func1 does not need func4. The linker only sees the defined reference in test1.so to func4. You can control this behaviour using the --unresolved-symbols option. See the documentation. > On HP-UX, the build is organized such that each directory produces an archive > library. Some of the directories produce binaries and I have the link command > line that is known to work on HP-UX. > However specifying same dependent libraries produce aforementioned errors on > linux. The linux build is using shared libraries. If the linker could figure > the minimum required dependencies, it will be a great help to me here. If the build worked using archive libraries on HP-UX, why not use archive libraries on Linux? Shared libraries are similar, but different. The easy way to use shared libraries in a similar fashion would be to use --as-needed and link against every shared library. Or to link all the objects together into a single shared library. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Reporting bugs in GAS
PatilSubhash Jayadeep <[EMAIL PROTECTED]> writes: > Please let me know where can I report GNU Assembler bugs. http://sourceware.org/bugzilla/ Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/847] New: Error: Zero-length symbol is illegal
Nick Clifton <[EMAIL PROTECTED]> writes: > > The ia64 assembler is choking on `.file ""' with the error message > > "Zero-length symbol is illegal". According to the GAS manual this > > should be allowed. The problem is that gcc 3.4 and later now uses > > `.file ""' instead of `.file ""' when input comes from stdin. > > Hmm, well the documentation does also say that the feature is only > supported for backwards compatibility and may go away in the future. > > Still a patch for this problem seems fairly straight forward. > > Jan, Ian - what do you think of this ? > > Cheers >Nick > > gas/ChangeLog > 2005-04-15 Nick Clifton <[EMAIL PROTECTED]> > > PR gas/847 > * read.c (s_app_file): Call tc_convert_file_name, if defined, > before s_app_file_string. > * config/tc-ia64.c (ia64_convert_file_name): Define. Convert > empty file names into "". > * config/tc-ia64.h (tc_convert_file_name): Define. Why does ia64_canonicalize_symbol_name reject a symbol with no name? ELF permits them. Perhaps there are places which call canonicalize_symbol_name which want to reject empty symbol names, but I don't see why they should be rejected in canonicalize_symbol_name itself. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: no -mthumb-interwork support for ld in an arm-thumb cross-compiler toolset
Marshall Ward <[EMAIL PROTECTED]> writes: > The build is successful and I can use the linker, arm-thumb-elf-ld to > produce ARM opcode. But when I try to link using the interworking tag, > > arm-thumb-elf-ld --mthumb-interwork (+ other stuff) > > I get the following error message: > > arm-thumb-elf-ld: unrecognised emulation mode: thumb-interwork -mthumb-interwork is a compiler option, not a linker option. It's normally best to link with the compiler. The compiler driver will invoke the linker with the appropriate options. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gprof : histogram records
Lilia Ghachem <[EMAIL PROTECTED]> writes: > I have a question about the number of histogram records in the profile > data file: gmon.out file : Can we have more than ONE histogram record? > in all the tests I made, I found just 1 ... > So If it's not the case, where these histogram records are stored? > (list, vector..?) The gprof program is only prepared to see a single histogram record in a gmon.out file. So I think it is fairly safe to assume that a gmon.out file will have only one histogram. More precisely, gprof can use more than histogram, but they must cover the same range of the program--same low PC, high PC, number of bins, and profiling rate. Support multiple histograms over the same executable space is intended to let you generate multiple gmon.out files from a single executable and combine them in a single gprof run. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: libiberty vasprintf bug, doesn't handle long longs
Doug Evans <[EMAIL PROTECTED]> writes: > Who owns libiberty? Do I file a bugzilla for binutils or gcc or ? gcc owns libiberty, so: http://gcc.gnu.org/bugzilla/ > vasprintf doesn't watch for long longs so the va_arg() calls > can get out of sync with what's passed. Yeah, vasprintf probably needs a full overhaul for C99. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld unwilling to find libs in configured paths
Dennis Heuer <[EMAIL PROTECTED]> writes: > Today I installed a new i386 linux system from source with linux 2.6.16, > gcc 4.1.0, glibc 2.4, and binutils 2.16. The problem I have is that ld > refuses to detect libraries at other locations than /lib and /usr/lib > though ld.so.conf and (LD_)LIBRARY_PATH are set correctly. ld can > link a lib correctly if the path is specified with -L. ldconfig -p > prints out the correct paths to the problematic libs, and recreating > the cache doesn't change the situation. I installed binutils 2.17 (from > ftp.kernel.org) and the newest libtool (for the case that it is somehow > related to ld's internals) but nothing changed. If it's not the usual > configuration issues, what else can be missing? I know this is confusing, but ld (not ld.so) does not use ld.so.conf or LD_LIBRARY_PATH to find libraries specified on the command line. It only uses the -L option. When invoked from gcc, the gcc driver itself will convert the environment variable LIBRARY_PATH (not LD_LIBRARY_PATH) to -L options to pass to the linker. The linker itself ignores LIBRARY_PATH. ldconfig tells you what ld.so will do, not what ld will do. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
doctor electron <[EMAIL PROTECTED]> writes: > As author of the HotBasic compiler for Windows, in porting same > to Linux, I find that ld does not properly link relative > relocations (R_386_PC32) in correct elf32-i386 .o files. GNU ld is correct according to the ELF ABI Processor Supplement for i386 Processors. In typical use, the .o file will contain a 0xfffc in the four bytes affected by R_386_PC32. R_386_PC32 is defined to add the PC relative offset from the start of the 4 byte field to the existing contents of the 4 byte field. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
doctor electron <[EMAIL PROTECTED]> writes: > >> As author of the HotBasic compiler for Windows, in porting same > >> to Linux, I find that ld does not properly link relative > >> relocations (R_386_PC32) in correct elf32-i386 .o files. > > > >GNU ld is correct according to the ELF ABI Processor Supplement for > >i386 Processors. > > Thank you for your reply, Ian. The first smoking gun was > described in my first email: ld overshoots the target for rel > relocs within module by 4 bytes. This is undeniably a linker > failure. The processor adds the value in the rel relocated > address to eip ... and, period; that's it. ld does not know how > i386 and essentially all other microprocessors work. There is > no other credible explanation. Please allow me to repeat: GNU ld is correct according to the ELF ABI Processor Supplement for i386 Processors. If you want to convince anybody, you need to start by reading that document and explaining where GNU ld fails to follow it precisely. > The one and only formula for rel relocs is: > > S - (A + 4) That turns out not to be the case. Read the ABI. > Notice that the contents of that E8 field in the > .obj or .o is irrelevant, it should be overwritten. That turns out not to be the case. Read the ABI. > [This is why it looks ridiculous (!) to see -4 in these > locations in existing linux .o and .so files -- really looks > like people have no idea what they are doing -- KeyStone Cops. > I would like to be an advocate/promoter of Linux, but this, my > friend, is totally second-class.] I note that when we wrote this code Eric Youngdale and I tested it against the ELF linker independently developed for i386 UnixWare (an SVR4 port). The GNU linker correctly handled UnixWare .o files, and vice-versa. So this is hardly a Linux-specific issue. > So I humbly ask again: Where is this code, so e might best find > this code in ld, rewrite it correctly, and then ld would link > all i386 formats, for both good and existing (contain the -4 > gibberish) input files. Look for R_386_PC32 in bfd/elf32-i386.c. But consider the alternatives: 1) Every single existing i386 ELF object file is wrong, every existing i386 ELF linker is wrong, every existing i386 ELF assembler is wrong, the i386 ELF ABI is wrong. or 2) You are wrong. Between those two, I know which one I would pick. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
doctor electron <[EMAIL PROTECTED]> writes: > As you might see in Ian's thoughtful reply, I don't think he > gets the point (maybe my failure to communicate well): I completely understood what you said. > ld can get the -4 on its own, rather than read it from "typical" > input files and thereby conform to the rel reloc formula *and* > remove the requirement that .o files contain -4 at all those > locations, which must be a continuing source of shame and > embarrassment to writers of existing Linux compilers (nasm, C, > etc). Note that if ld coughs up its own -4 (per the formula I > posted), all the existing .o/.so files would still link -- the > -4 is a *constant* in the hardware-based formula and its > presence in those .o/.so files should properly be ignored [so > correct input files with any arbitrary value (e.g., 0) in those > locations would also link]. If you ignore the contents of the .o file, then how do you propose to handle the assembler code call foo + 16 ? With the ELF ABI as designed and implemented, it is easy. This type of code can arise when the compiler implements alternate entry points for functions: one external to the file and one internal. > Notice Ian gave no rationale beyond what I might call "This is > the way we do it" and "Some ABI document covers us", as if any > document changes how existing processors work. We have an ABI so that all tools agree on the processing of i386 ELF input files. The ABI was written at AT&T, the designers of the ELF format, back in 1990 when the ELF object file format was first designed. In order for tools to interoperate, they must all implement the same ABI. And they do. And that ABI says that R_386_PC32 is implemented by adding the offset from the address to the contents of the four byte field. There is no -4 in the formula. Note that 1990, when these rules were laid down, was before the Linus had even started working on the Linux kernel, and long before the Linux kernel supported ELF (Linux originally used the a.out object file format). So when you describe this as a Linux issue, you just sound ignorant of history. There are several systems besides Linux which implement the i386 ELF ABI, and .o files for those systems all interoperate correctly. > From what we see in this thread of posts, will they have nothing > credible that makes any sense -- other than some ABI doc says > it's OK? The enquiring public will want more substance than > that. OK, now you're just being a troll. > Why do Linux developers appear to want to keep correct .o files > (no -4 constants in there) out of the Linux environment? Is the > intent to keep quality software out of the Linux environment? > The larger computing world outside Linux/Sun, etc, also has > smart people producing useful object files -- in business, math, > science, you name it. But ld does not know how to link them! If those object files are ELF, then ld knows how to link them. If they are not ELF, then ld follows the rules appropriate for the object file format. > What message are you sending? That we know how to follow published standards and interoperate with other tools. > Is the message that objcopy writers now must also go in and > insert the -4's in .text sections when converting from .obj to > .o? All because ld can't find its own -4? [Free gift, cut and > paste any -4 in this post and put it in ld source code!] Is that the context of all this babble? You want to convert from .obj files, presumably in the Windows PE/COFF object file format, to object files in the ELF file format? If you want to do that conversion, then subtracting 4 from the contents of the section for PC relative relocs is the least of the issues you are going to have to deal with. Or, if you have a compiler which generates PE/COFF and you want to generate ELF, then just produce assembly code and feed it into an ELF assembler. The right thing will happen. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
Airr <[EMAIL PROTECTED]> writes: > As of late yesterday evening, we've been able to get this to work by > linking the .obj (PE/COFF) files with ld emitting a PE executable, and > then using objcopy to convert to the final ELF executable. Yes, that is the usual technique. Of course it only works with a fully statically linked program. > So, is it safe to assume that attempting the conversion using ld alone > will not produce a working ELF file in our case? That instead we > should use objcopy to produce the final file? Yes. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
doctor electron <[EMAIL PROTECTED]> writes: > 2. As one who finds much in Linux to be very praiseworthy, I > worry a bit about what seems to be such allegiance to a > 20-year-old ABI doc which may be inconsistent with making > quality improvements in the future. [No hardware maker would do > such a thing, I think, and survive; no one makes 16 bit bus > cards anymore.] In short, the interoperability rationale may > loose its punch if the thing to be interoperable should best be > discarded. We would discard the ABI in a second if the benefit exceeds the cost. What benefit would we gain by changing the definition of R_386_PC32? You have not described any benefit beyond abstract appeals to what you think object files should look like. That doesn't count. Give us a measurable benefit and we'll consider it. A vague hand-waving notion of how you think it should work means nothing. A complaint that the current ELF ABI makes it harder to convert PE/COFF object files to ELF means nothing; it's already hard to do that conversion. > First, we might call this the "Laziness concession to compiler > writers" in that they don't have to evaluate "foo + 16" above > and just put it in the reloc table, with an autogenerated > textual symbol if necessary, as "good boys and girls" would. If > the contents of the rel reloc location were simply ignored, the > message to compiler writers is that this splitting of reloc info > is no longer supported, in favor of the "regular" simpler, > cleaner rel reloc relocation table entry. Supporting lazy compiler writers is not a benefit. > Second, the -4 constant is still embedded in the location > contents read by the linker -- another place where one could > break with ABI. If linkers just used a -4 constant and the rel > reloc info in the relocation table, in effect, some advantages > of interoperability would be gained (all the .obj files would > link, whether in .obj or .o form from objcopy), and compiler > splitting of rel reloc info would be discarded. Changing this would not permit interoperability of .obj files. There are many other issues to consider. This one is quite minor compared to others. Therefore, this is not a benefit. > The above may not be the point to break with ABI, but my > friendly message is that major quality upgrades may be found by > dropping provisions which are not presently deemed to be > optimally efficient. Of course, this is contrary to the "ABI is > written in stone" concept. Nobody said the ABI is written in stone. We said that we follow the ABI, and we do that for a reason, and there is a cost to changing. You have not demonstrated any meaningful benefit to changing. > If I understand, Microsoft has broken with ABI specs (e.g., they > put 0 in the location to undergo rel relocation) and lightning > did not strike them dead (actually, they have done just fine > after doing so). You are confused. Since Microsoft does not generate ELF files, they use a different ABI, specifically the PE/COFF ABI which is available from MSDN. That ABI specifies a different handling for PC relative relocations. I assure you that Microsoft follows the PE/COFF ABI just as rigorously as we follow the ELF ABI. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
doctor electron <[EMAIL PROTECTED]> writes: > >You have not described any benefit beyond abstract appeals to what you > >think object files should look like. That doesn't count. Give us a > >measurable benefit and we'll consider it. > > I did: the vast amount of .obj files containing useful > procedures would become "interoperable". In terms of available > software, one might estimate 10x more .obj files than .o files > worldwide. Just to be excruciatingly clear, when ld links a .obj file, it naturally applies the PE/COFF relocation calculation, not the ELF relocation calculation. It is not the case that simply changing the ELF calculation will make .obj files interoperable with ELF files. In principle ld can link PE/COFF input files to generate an ELF output file. In practice that rarely works because the shared library (DLL) model is completely different. The problem there is not the relocation processing. Because this type of linking so rarely works, it is rarely used, and there are probably a number of problems with it. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: relocation entries for absolute symbols
Amit Gud <[EMAIL PROTECTED]> writes: > I'm compiling the GNU/Linux kernel as a shared library and I've found > that relocation entries are created even for absolute symbols. Is > there any work-around for this, or is it a known bug? That is correct behaviour if the symbol is globally visible. In a shared library, by default, any symbol may be overridden by the main executable. That means that a relocation entry is required. One fix would be to force the symbol to be hidden using an attribute or a linker script. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
[EMAIL PROTECTED] (Joerg Schilling) writes: [EMAIL PROTECTED] (Joerg Schilling) writes: > Eric Botcazou <[EMAIL PROTECTED]> wrote: > > > > Well, Sun did invent ELF, so an extension to ELF made by Sun seems to be > > > an > > > official extension that should be supported by all tools. > > > > You're rewriting history, ELF was invented by UNIX System Laboratories. > > Can you prove that please? > > The first time I heard about ELF was with a talk held by Bill Joy on a Sun > user > group meeting in 1987. ELF was used in SVR4 long before Sun adopted it when they moved from SunOS to Solaris. That said, the version of ELF used in SVR4 was closely based on the shared library implementation Sun used with the a.out object file format in SunOS 4. To me it seems that Sun developed the basic ideas, and AT&T Unix System Laboratories codified it into a complete standard. A particular idea which AT&T added which was not in SunOS was the separation of sections and segments. Either way, it's really irrelevant to the original point. Many people other than Sun use ELF. The registry of ELF numbers is held at SCO. There is an ELF ABI group which has meet occasionally with representatives from many companies. Sun is free to extend ELF using the defined extension capability, and that is what they have done. Extensions written at Sun do not automatically become part of the ELF standard. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris
[EMAIL PROTECTED] (Joerg Schilling) writes: > Ian Lance Taylor wrote: > > > > group meeting in 1987. > > > > ELF was used in SVR4 long before Sun adopted it when they moved from > > SunOS to Solaris. That said, the version of ELF used in SVR4 was > > closely based on the shared library implementation Sun used with the > > a.out object file format in SunOS 4. > > > > This is definitely a wrong interpretation: And yet that paragraph is, I believe, completely correct. You didn't dispute anything I said in it. I won't reply further on this thread, since it is pointless. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Memory leak in ld.so-2.4
Seweryn Habdank-Wojewódzki <[EMAIL PROTECTED]> writes: > There is a memory leak in ld.so. > > A piece of valgrind log file is: > > ==9293== at 0x402073E: calloc (in > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > ==9293== by 0x40105C8: allocate_dtv (in /lib/ld-2.4.so) > ==9293== by 0x401068B: _dl_allocate_tls (in /lib/ld-2.4.so) > ==9293== by 0x40589FF: pthread_create@@GLIBC_2.1 > (in /lib/libpthread-2.4.so) Thanks for the report. However, despite the name, ld-2.4.so is not part of the GNU binutils. It is part of GNU libc. Please see http://sourceware.org/glibc/ for where to report the problem. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold: script_test_3.t output produces exec format error
Jan Blunck <[EMAIL PROTECTED]> writes: > Although the linker script looks ok, the resulting binary isn't executable on > x86_64. Without defining the program headers in the linker script the > executable is working fine. What happens if you use -z max-page-size=0x10 ? I have tested this on x86_64 running Ubuntu 6.06, by the way, with kernel 2.6.18, and it worked fine. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug admin/6105] New: fssv0o
Paul Koning <[EMAIL PROTECTED]> writes: > Does anyone have the power to blacklist all traffic from > *.phenblogs.cc ? They are blocked. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold-linked binary for ppc results in "illegal instruction"
"Sebastian Klaar" writes: > I am using gold v1.11 (binutils v2.2) for cross-linking a program for my > powerpc architecture. > When I execute this binary I am getting an "Illegal instruction". > Readelf delivers a correct fileheader (Machine: PowerPC). > > Linking with the standard GNU ld creates a runnable binary, but of course > needs a lot longer. > > I compiled gold before for arm. Worked like a charm! The gold PowerPC support is incomplete. Sorry. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: error compiling binutils-2.22 with clang v2.9
Roy Batty writes: > i don't know if your project even has an interest in being compiled with > anything other than GCC @ this point in time, but here is an error I found > when trying to make binutils with clang. note that this was performed on a > fairly standard fedora 16 x86_64-bit install ( using > kernel 3.2.9-1.fc16.x86_64 #1 SMP ) ... hope this is of some use to your > project. let me know if you need further information. > > > > libtool: compile: clang -DHAVE_CONFIG_H -I. -I. -I. -I./../include > -DHAVE_bfd_elf64_x86_64_vec -DHAVE_bfd_elf32_i386_vec > -DHAVE_bfd_elf32_x86_64_vec -DHAVE_i386linux_vec -DHAVE_i386pei_vec > -DHAVE_x86_64pei_vec -DHAVE_bfd_elf64_l1om_vec -DHAVE_bfd_elf64_k1om_vec > -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec > -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec > -DBINDIR=\"/usr/local/bin\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wshadow -Werror -g -O2 -MT opncls.lo -MD -MP -MF .deps/opncls.Tpo -c > opncls.c -o opncls.o > opncls.c:249:5: error: expression result unused [-Werror,-Wunused-value] > bfd_set_cacheable (nbfd, TRUE); > ^~ > In file included from opncls.c:26: > ./bfd.h:524:67: note: instantiated from: > #define bfd_set_cacheable(abfd,bool) (((abfd)->cacheable = bool), TRUE) > ^ > ./bfd.h:127:14: note: instantiated from: > #define TRUE 1 > ^ > 1 error generated. > *** Error code 1 There is nothing wrong with this code. It is working as intended. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold mistreats -Wl,-Ttext,0x8200
"Vladimir 'φ-coder/phcoder' Serbinenko" writes: > Namely the minimal testcase is: > gcc -o 1.img -ffreestanding -Wl,-Ttext,0x8200 1.S -nostdlib -m32 > The resulting file has .text at 9200 and not 8200 > 1.S: > .text > > .globl _start > _start: Thanks for the report. For gold the -Ttext option sets the address of the text segment, not the .text section. When I try your test case with current gold the text segment does indeed start at 0x8200, as expected. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold mistreats -Wl,-Ttext,0x8200
"Vladimir 'φ-coder/phcoder' Serbinenko" writes: > On 10.03.2012 19:19, Ian Lance Taylor wrote: > >> "Vladimir 'φ-coder/phcoder' Serbinenko" writes: >> >>> Namely the minimal testcase is: >>> gcc -o 1.img -ffreestanding -Wl,-Ttext,0x8200 1.S -nostdlib -m32 >>> The resulting file has .text at 9200 and not 8200 >>> 1.S: >>> .text >>> >>> .globl _start >>> _start: >> >> Thanks for the report. For gold the -Ttext option sets the address of >> the text segment, not the .text section. When I try your test case with >> current gold the text segment does indeed start at 0x8200, as expected. >> > > Hello, I still do need a way to put everything in one chunk without > holes which starts at a given address. Otherwise GRUB can't be compiled > with gold. Are you saying that you can not do this with gold? Please open a complete bug report at http://sourceware.org/bugzilla , with the files needed to recreate the problem. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Glibc installation
Apurva Shirish Patil writes: > While building glibc , one of the pre-requisits is to configure > and build binutils. While running make after doing ./configure we are > getting the following errors : > > Aborted > make[3]: *** [libbfd.la] Error 134 > make[3]: Leaving directory > `/home/student/Desktop/glibc/binutils-2.14/bfd' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/student/Desktop/glibc/binutils-2.14/bfd' > make[1]: *** [all-recursive-am] Error 2 > make[1]: Leaving directory > `/home/student/Desktop/glibc/binutils-2.14/bfd' > make: *** [all-bfd] Error 2 You need to show us more lines of the make output. That is not enough to see what has gone wrong. That said, make sure you did not run out of disk space. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Current binutils snapshots archives missing sequence number?
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" writes: > There used to be something like a snapshot sequence number (52, 90) like in > these: > > binutils-2.22.52.tar.bz2 21249 KB7/27/2012 12:00:00 AM > binutils-2.22.90.tar.bz2 20362 KB7/27/2012 12:00:00 AM > > but seems no longer to be the case for more recent snapshot(s): > > binutils-2.23.0.tar.bz2 20948 KB11/6/2012 9:05:00 AM > binutils.tar.bz2 22594 KB3/18/2013 5:43:00 AM > binutils-.tar.bz2 22594 KB3/18/2013 5:43:00 AM This may have been broken since this change: 2012-07-27 Mike Frysinger * configure.in (AC_INIT): Call with the args bfd and 2.22.52. (AM_INIT_AUTOMAKE): Remove args. See the way that VER is set in the top-level src-release script. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Global symbol demangling issue in c++filt
Bryan Ta writes: > I encountered the following bugs about global symbol demangling in c++filt > versions 2.23 and 2.22. Could you please tell me how to fix it? > >> c++filt _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE > _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE I'm not quite sure what this means, but certainly the demangler doesn't handle it. g++ seems to generate it to run a set of global constructors. Please file a bug report with a test case as described at http://gcc.gnu.org/bugs/ . Thanks. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: how to get binutils gold on osx
Timothee Cour writes: > I'm trying to get gold on osx; > i tried homebrew binutils but it seems to install everything except gold > I tried configure make from git head but it fails ( Bug 16644) The gold linker doesn't work on OS X or Windows. It only supports systems that use ELF. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Possibly a typo in function prototype
pbo writes: > Confidentiality Notice: The information contained in this e-mail and > any accompanying attachment(s) is intended only for the use of the > intended recipient and may be confidential and/or privileged of > Neusoft Corporation, its subsidiaries and/or its affiliates. If any > reader of this communication is not the intended recipient, > unauthorized use, forwarding, printing, storing, disclosure or > copying is strictly prohibited, and may be unlawful.If you have > received this communication in error,please immediately notify the > sender by return e-mail, and delete the original message and all > copies from your system. Thank > you. > --- I was going to answer, but I saw this. Please avoid sending e-mail messages with this kind of disclaimer to the binutils mailing list. They are against list policy. We can not honor the disclaimer, as the list is publically archived. If your company does not permit you to send e-mail without the disclaimer, consider using a free webmail account instead. Thanks. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Potential Licensing Problem in binutils-2.29/gas/config/tc-alpha.c
"Fendt, Oliver" writes: > I think there is a potential licensing problem in the file > binutils-2.29/gas/config/tc-alpha.c > > The license information in the beginning of the files says that this > file is licensed under GPL-3.0+ ; below this information the CMU > License is listed. This suggests that the file itself stays under > GPL-3.0 and CMU. > The CMU has among others wording that reads: > > Carnegie Mellon requests users of this software to return to > > ??? Software Distribution Coordinator? or? software.distribut...@cs.cmu.edu > ??? School of Computer Science > ??? Carnegie Mellon University > ??? Pittsburgh PA 15213-3890 > ? any improvements or extensions that they make and grant Carnegie the > ?? rights to redistribute these changes.? */ > > so it is requested that all modifications are sent back to the > CMU. Such a requirement is not formulated in the GPL-3.0 and the > GPL-3.0 says in section It's only a request, not a requirement. I don't see a problem here. I do kind of wonder what that text is doing on an Alpha source file. As far as I know Mach never ran on the Alpha. Our repository history don't go back far enough to show where it came from. I suppose we could ask Richard Henderson to see if he remembers. I also wonder how many people would notice if we just dropped Alpha support. They stopped selling Alpha machines ten years ago. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -mfence-as-lock-add option in binutils 2.27
Parul Chahar writes: > I found that a new option "-mfence-as-lock-add" is added in binutils 2.27. > It generate lock instruction when "-mfence-as-lock-add=yes". Otherwise, > mfence, lfence, sfence is generated. > > Please let me know why this option is required. Why lock instruction is > needed. It's not needed, but it can be more efficient. See, for example, https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_hardware Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: FW: binutils-gdb.git: connection timed out
"Dey, Shantanu" writes: > We are not able to download the following: > > git clone git://sourceware.org/git/binutils-gdb.git > > Please let us know if there is any issue related to the server. It's working for me. Does `git clone git:...` work for you using other sites? Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug Report ( sensitive information on Github )
kunal mhaske writes: > Any update on this? I don't understand why you are reporting this to bug-binutils@gnu.org. Ian
Re: Bug Report ( sensitive information on Github )
kunal mhaske writes: > Because the github leak the your engineers id and password You seem to be confusing binut...@sourceware.org with a Red Hat mailing list. Ian > On Thu 5 Dec, 2019, 9:41 PM Ian Lance Taylor, wrote: > >> kunal mhaske writes: >> >> > Any update on this? >> >> I don't understand why you are reporting this to bug-binutils@gnu.org. >> >> Ian >>
Re: FW: objdump says 'no recognized debugging informatio'
Sharath Manjunatha <[EMAIL PROTECTED]> writes: > Can anybody tell me, why the below message comes while using "objdump" > on an object > > 1.o: no recognized debugging informatio > > 1.o is the object generated by gcc -c -g 1.c -o 1.o Are you using objdump -g? Nobody ever added support for DWARF debugging information to that. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: FW: objdump says 'no recognized debugging informatio'
Sharath Manjunatha <[EMAIL PROTECTED]> writes: > I am using '--debugging' option for the objdump. Is that you are asking? Yes, --debugging is the same as -g. Neither option supports DWARF. > And I am using the object compiled with 345 compiler. I don't know what that compiler is. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold and shared objects with gcc 4.1.2
Roland Baumann writes:
> I have a problem with gcc 4.1.2 and the gold linker (from binutils
> 2.19). We build shared objects with options "-s" and "-shared"
> together. This leads to assertions in the gold linker. In most cases I
> see
>
> .../gold/real-ld: internal error in get_output_view, at
> ...src/binutils-2.19/gold/output.h:3081
> collect2: ld returned 1 exit status
>
> But for the very simple example provided below, I see a different assertion:
>
> .../gold/real-ld: internal error in write_local_symbols, at
> .../src/binutils-2.19/gold/object.cc:1471
> collect2: ld returned 1 exit status
>
> The example to trigger this error is:
>
> --
> #include
> void print() {
> std::cout << "Hello World!" << std::endl;
> }
> --
>
> I compile this with:
>
>> g++-4.1.2 -c test_shared.cc -o test_shared.o
>> g++-4.1.2 -B -shared -s test_shared.o -o test_shared.so
I'm not able to recreate this problem with either binutils 2.19 or
with the development version. Can you post the output of your -shared
command line with the -v option? That will show precisely how the
linker is being invoked.
Also, for which target did you configure?
Ian
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold and shared objects with gcc 4.1.2
Roland Baumann writes:
>>>
>>> I compile this with:
>>>
>>>> g++-4.1.2 -c test_shared.cc -o test_shared.o
>>>> g++-4.1.2 -B -shared -s test_shared.o -o test_shared.so
>>
>> I'm not able to recreate this problem with either binutils 2.19 or
>> with the development version. Can you post the output of your -shared
>> command line with the -v option? That will show precisely how the
>> linker is being invoked.
>>
>
> Here it comes:
Thanks. Unfortunately I still can't recreate it.
I took a closer look at the code, and I found a possible problem if
there are local symbols which have to go into the dynamic symbol
table. I committed this patch, which may fix your problem.
Ian
2009-01-15 Ian Lance Taylor
* object.cc (Sized_relobj::write_local_symbols): Don't write out
local symbols when stripping all symbols.
Index: object.cc
===
RCS file: /cvs/src/src/gold/object.cc,v
retrieving revision 1.79
diff -p -u -r1.79 object.cc
--- object.cc 23 Dec 2008 02:02:20 - 1.79
+++ object.cc 15 Jan 2009 18:01:55 -
@@ -1416,9 +1416,13 @@ Sized_relobj::write_lo
Output_symtab_xindex* symtab_xindex,
Output_symtab_xindex* dynsym_xindex)
{
- if (parameters->options().strip_all()
- && this->output_local_dynsym_count_ == 0)
-return;
+ const bool strip_all = parameters->options().strip_all();
+ if (strip_all)
+{
+ if (this->output_local_dynsym_count_ == 0)
+ return;
+ this->output_local_symbol_count_ = 0;
+}
gold_assert(this->symtab_shndx_ != -1U);
if (this->symtab_shndx_ == 0)
@@ -1487,7 +1491,7 @@ Sized_relobj::write_lo
st_shndx = out_sections[st_shndx]->out_shndx();
if (st_shndx >= elfcpp::SHN_LORESERVE)
{
- if (lv.needs_output_symtab_entry())
+ if (lv.needs_output_symtab_entry() && !strip_all)
symtab_xindex->add(lv.output_symtab_index(), st_shndx);
if (lv.needs_output_dynsym_entry())
dynsym_xindex->add(lv.output_dynsym_index(), st_shndx);
@@ -1496,8 +1500,7 @@ Sized_relobj::write_lo
}
// Write the symbol to the output symbol table.
- if (!parameters->options().strip_all()
- && lv.needs_output_symtab_entry())
+ if (!strip_all && lv.needs_output_symtab_entry())
{
elfcpp::Sym_write osym(ov);
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold and shared objects with gcc 4.1.2
Roland Baumann writes: > this patch indeed fixes my problem. Thanks a lot. You're welcome. Thanks for reporting the bug. > Actually, I am wondering whether it makes sense to use "-s" and > "-shared" together. What information stays in the shared object that I > am still able to link it? An ELF shared object has two symbol tables: the dynamic symbol table and the normal symbol table. The -s option removes the normal symbol table. The dynamic symbol table contains whatever is needed for dynamic linking. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold: problems with mixed C++/Fortran program
tuebened...@yahoo.de writes: > Not being a linking expert, I assume the object code of fortran > subroutines is compatible to objects derived from C code. Am I wrong? Yes, the object code should be compatible. > === > And now for the details: You will find > > 1) file list > 2) Makefile > 3/4) C++ test class source and header > 5/6) Fortran test routine source and header > 7) main routine in test.C > 8) version strings of the compilers and linkers used > 9) compile and run log using GNU ld (--> this output is what I expected!) > 10) compile and run log using GNU gold > (--> search for "Hi guys..." strange,isn't it? I think it isn't just a C/F90 > problem.) Thanks for the detailed bug report. Unfortunately, I can't do anything with it as I don't have the icpc or ifort programs. Also unfortunately, in order to get a reproducible test case I would most likely need to have the libraries, which you are probably not allowed to send me. The difference in the output appears to be in the strings. This suggests that your compilers are behaving differently than I expect with respect to references to entries in string merge sections. Can you send me just the file TestClass.o? That might be enough for me to see the problem. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold: problems with mixed C++/Fortran program
b...@gmx.net writes: >> The difference in the output appears to be in the strings. This >> suggests that your compilers are behaving differently than I expect with >> respect to references to entries in string merge sections. Can you send >> me just the file TestClass.o? That might be enough for me to see the >> problem. > Yes, in the tarball below. See the directories using_*ld Thanks for sending the object files. Now I remember. I've seen this problem before and reported it to Intel before. They are generating object files which do not follow the x86_64 ELF ABI. The x86_64 ELF ABI specifies that the relocation computation for R_X86_64_32 is simply "S + A". The ABI says: S Represents the value of the symbol whose index resides in the relocation entry. A Represents the addend used to compute the value of the relocatable field. The AMD64 ABI architectures uses only Elf64_Rela relocation entries with explicit addends. The r_addend member serves as the relocation addend. So this is all clear enough, and gas complies with it. However, in the object file you sent me, I see this using objdump -dr: 142: ba 14 00 00 00 mov$0x14,%edx 143: R_X86_64_32.rodata and this using readelf -r: 0143 000d000a R_X86_64_32 .rodata + 0 As you can see, the r_addend member for this relocation has the value 0. There is a 0x14 stored in the instruction itself, but the x86_64 ELF ABI says that that field should be ignored. As it happens, the GNU linker does not ignore that field. It incorrectly adds the value in the field in the instruction into the final relocation value. (This is because the src_mask field in the howto entry for R_X86_64_32 in bfd/elf64-x86-64.c is 0x when it should be 0; this bug dates back to the initial creation of the file). That is why this object file works with the GNU linker. So the problem that gold faces is whether it should adhere to the published ABI, or whether it should emulate the GNU linker. Adhering to the published ABI does work correctly with output from the GNU tools. Unfortunately, as you have discovered, the Intel tools generate incorrect output which does not follow the ABI, and gold does not work with them. My preference would be for Intel to fix their tools to conform to the published ABI. Then there will be no confusion going forward. If you have purchased a copy of the Intel compilers, I encourage you to report the bug. I would be happy to provide more details and arguments if required. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug in objcopy?
"Arshid, Chetan (IE10)" writes: > I tried to rename the section (of .o file) .data to .persistent.data > using objcopy utility. It did that, but also renamed the section > .rela.data to .rela.persistent. I think this is a bug. If not, how do > I keep the .rela.data section name unchanged? It doesn't sound like a bug. Normally the .rela.XXX section applies to the .XXX section. If you rename a section, it seems natural to rename the corresponding .rela section. As far as I know there is no way to keep this from happening. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug in objcopy?
"Arshid, Chetan (IE10)" writes: > Thanks Ian for the explanation. Can you tell me what kind of data is > put in .rela.XXX section? Relocation information. It is displayed by readelf -r or objdump -r. Ian > -Original Message- > From: Ian Lance Taylor [mailto:i...@airs.com] > Sent: Saturday, May 23, 2009 12:10 PM > To: Arshid, Chetan (IE10) > Cc: bug-binutils@gnu.org > Subject: Re: Bug in objcopy? > > "Arshid, Chetan (IE10)" writes: > >> I tried to rename the section (of .o file) .data to .persistent.data >> using objcopy utility. It did that, but also renamed the section >> .rela.data to .rela.persistent. I think this is a bug. If not, how > do >> I keep the .rela.data section name unchanged? > > It doesn't sound like a bug. Normally the .rela.XXX section applies > to the .XXX section. If you rename a section, it seems natural to > rename the corresponding .rela section. > > As far as I know there is no way to keep this from happening. > > Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: nondeterministic symbols relocation
Giuseppe Scrivano writes: > I noticed that ld relocates symbols assigning them always the same > values in a deterministic way. I am quite sure this is the desired > behaviour but wouldn't be better to add a bit of randomness? > Buffer overflow exploits can take advantage to know in advance the > position of a symbol, it will not solve completely the problem but > surely it will make things harder. > > Does something similar already exist? Is it a reasonable idea? Exploits which rely on the position of symbols are based on popular binaries which have already been linked. Binaries are not routinely relinked. Randomizing the behaviour at relink time would have a vanishingly small effect on security. Randomizing addresses at runtime would have slightly more effect. That is already implemented in the linker and GNU/Linux kernel, via -pie. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: 32bits specific code in do_adjust_elf_header()
Roman Divacky writes:
> Target_freebsd::do_adjust_elf_header()
>
> there is 32specific code that does not work on 64bit platforms
>
> this:
>
> gold_assert(len == elfcpp::Elf_sizes<32>::ehdr_size);
>
> elfcpp::Ehdr<32, false> ehdr(view);
>
>
> the 32 does not work on 64bit platform (ie. amd64), I believe
> it should be either 32 or 64. When I manually enter 64 there
> on amd64 gold works for me just fine.
Thanks for the report. I think it was just dumb coding on my part. I
committed this patch to fix it.
Ian
2009-07-01 Ian Lance Taylor
* freebsd.h (Target_freebsd::do_adjust_elf_header): Use size
instead of 32.
Index: freebsd.h
===
RCS file: /cvs/src/src/gold/freebsd.h,v
retrieving revision 1.1
diff -p -u -r1.1 freebsd.h
--- freebsd.h 24 Mar 2009 00:31:28 - 1.1
+++ freebsd.h 1 Jul 2009 16:20:44 -
@@ -68,15 +68,15 @@ Target_freebsd::do_adj
{
if (this->osabi_ != elfcpp::ELFOSABI_NONE)
{
- gold_assert(len == elfcpp::Elf_sizes<32>::ehdr_size);
+ gold_assert(len == elfcpp::Elf_sizes::ehdr_size);
- elfcpp::Ehdr<32, false> ehdr(view);
+ elfcpp::Ehdr ehdr(view);
unsigned char e_ident[elfcpp::EI_NIDENT];
memcpy(e_ident, ehdr.get_e_ident(), elfcpp::EI_NIDENT);
e_ident[elfcpp::EI_OSABI] = this->osabi_;
- elfcpp::Ehdr_write<32, false> oehdr(view);
+ elfcpp::Ehdr_write oehdr(view);
oehdr.put_e_ident(e_ident);
}
}
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: can't build gold on FreeBSD
Chris Jones writes: > I'm trying to get gccgo to go, using the latest sources from binutils > for gold. I did a quick google search, and this doesn't appear to be a > known bug. Any help would be greatly appreciated. What version of g++ are you using to build gold? Note that while it is useful to use gold with gccgo on x86/x86_64, there is currently no advantage to doing so on SPARC. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: can't build gold on FreeBSD
Chris Jones writes: > On 8/2/2010 9:10 AM, Ian Lance Taylor wrote: >> Chris Jones writes: >>> I'm trying to get gccgo to go, using the latest sources from binutils >>> for gold. I did a quick google search, and this doesn't appear to be a >>> known bug. Any help would be greatly appreciated. >> What version of g++ are you using to build gold? > > The stock one that comes with FreeBSD: > > maxwell$ g++ -v > Using built-in specs. > Target: i386-undermydesk-freebsd > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] Thanks. I committed a patch which should fix the problem. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: compilation error
Bin Zeng writes: > There is a compilation error when I tried to build binutils. > I checked out the fresh copy of binutils from the repository: > > cvs -z 9 -d :pserver:anon...@sourceware.org:/cvs/src co binutils > > I configure binutils to with --enable-gold --enable-plugins to enable > gold and plugins. > ../../src/gold/arm.cc:2135: internal compiler error: in > make_rtl_for_nonlocal_decl, at cp/decl.c:5067 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://bugzilla.redhat.com/bugzilla> for instructions. > Preprocessed source stored into /tmp/cczIynyz.out file, please attach > this to your bugreport. This is an internal compiler error from gcc. It's not a problem with the GNU binutils. Please report it as a gcc bug, either at the web site mentioned in the error message, or following the guidelines at http://gcc.gnu.org/bugs/ . Thanks. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: How to use control-D character?
ali hagigat writes: > My question is about as, GNU assembler, Version 2.14 and I have copied > the related extract from the manual: > - > 1.5 Input Files > If you give 'as' no file names it attempts to read one input file from > the as standard input, > which is normally your terminal. You may have to type ctl-D to tell as > there is no more > program to assemble. > > > How can i use key combination? Will it be typed at the end of > 'as' command line? > When i type: > as > 'as' will wait for user to enter some lines of instruction!! > > If I use 'as' alone and then enter some assembly lines , how can i > terminate the input terminal text and make 'as' assemble the lines I > have written? http://en.wikipedia.org/wiki/End-of-file In other words, type as your input file ^D This assumes that you are using Unix or GNU/Linux; you didn't say. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: How to use control-D character?
ali hagigat writes:
> Thank you to reply to my message. Ian, I am using Linux, Fedora 12.
> I typed 'as' as you wrote:
> root> as
> Then I wrote the name of my input file:
> root> asm1.s
> Then i pressed and then and nothing happned!
> For the second time I pressed and now I have the following
> error message:
> {standard input}: Assembler messages:
> {standard input}:1: Error: no such instruction: `asm1.s'
>
> I think you meant writing some assembly instructions before .
> But when I type:
> root> as
> root> mov $0, %eax
> root>
> nothing happens!! but if i press for two more times, it will
> exit from as and returns back to my shell prompt!
> So what happened? Did it assemble the line? Why this is
> useful, how it is used?
As noted in http://en.wikipedia.org/wiki/End-of-file , ^D is the
standard Unix end-of-file indicator from the terminal. You don't need
to use the caps lock or the shift key; pressing the control key and the
D key simultaneously is sufficient.
The fact that you have to type ^D more than once seems like a bug in the
GNU assembler. Please consider reporting it at
http://sourceware.org/bugzilla/ .
And, yes, when you do type it more than once, and the assembler exits,
then it has assembled the line you typed. You will find the results in
the file "a.out".
Ian
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: what the...???...
Peter Lawrence writes: > the question I have today is what is the point of all these > definitions being passed in as arguments to "make", shouldn't > this have been fixed by "configure", the Makefile is generated by > "configure", so all these definitions should have > been finalized at that point and the Makefile should already be wired > with the correct definitions, there should not be > any definitional arguments being passed in to make Passing the arguments down makes it easy for the user/developer to override them on the make command line, in a way that works reliably with various different implementations of make. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold linker issues with PostGIS cunit tests
Sandro Santilli writes: > This is : > binutils-gold 2.20.1-3ubuntu5 The Ubuntu distributors have decided to ship a version of gold which does not work with the version of libc that they ship. You need to use the gold from the binutils 2.21 release instead. See https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/673893 . Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gold cannot handle _start in a library
Roland McGrath writes:
> Given:
>
> $ gcc -c -xc <(echo '_start(){}') -o start.o
> $ ar cq libstart.a start.o
> $ ./gold/ld-new -o foo libstart.a
>
> The output file foo is an empty ELF file.
> With:
>
> $ ./gold/ld-new -o foo -e _start libstart.a
> ./gold/ld-new: warning: cannot find entry symbol '_start'
>
> The results are the same, plus the extra warning.
>
> BFD ld does not have this bug.
> I tested with today's trunk builds of gold and BFD ld.
Thanks. Fixed like so. Committed to mainline.
Ian
2011-05-24 Ian Lance Taylor
* archive.cc (Library_base::should_include_member): Pull in object
from archive if it defines the entry symbol.
* parameters.cc (Parameters::entry): New function.
* parameters.h (class Parameters): Declare entry.
* output.h (class Output_file_header): Remove entry_ field.
* output.cc (Output_file_header::Output_file_header): Remove entry
parameter. Change all callers.
(Output_file_header::entry): Use parameters->entry.
* gold.cc (queue_middle_tasks): Likewise.
* plugin.cc (Plugin_hook::run): Likewise.
Index: archive.cc
===
RCS file: /cvs/src/src/gold/archive.cc,v
retrieving revision 1.67
diff -p -u -r1.67 archive.cc
--- archive.cc 12 Apr 2011 00:44:47 - 1.67
+++ archive.cc 25 May 2011 00:11:15 -
@@ -113,6 +113,11 @@ Library_base::should_include_member(Symb
*why = buf;
delete[] buf;
}
+ else if (strcmp(sym_name, parameters->entry()) == 0)
+ {
+ *why = "entry symbol ";
+ *why += sym_name;
+ }
else
return Library_base::SHOULD_INCLUDE_UNKNOWN;
}
Index: gold.cc
===
RCS file: /cvs/src/src/gold/gold.cc,v
retrieving revision 1.89
diff -p -u -r1.89 gold.cc
--- gold.cc 24 May 2011 23:31:06 - 1.89
+++ gold.cc 25 May 2011 00:11:15 -
@@ -501,11 +501,7 @@ queue_middle_tasks(const General_options
if (parameters->options().gc_sections())
{
// Find the start symbol if any.
- Symbol* start_sym;
- if (parameters->options().entry())
-start_sym = symtab->lookup(parameters->options().entry());
- else
-start_sym = symtab->lookup("_start");
+ Symbol* start_sym = symtab->lookup(parameters->entry());
if (start_sym != NULL)
{
bool is_ordinary;
Index: layout.cc
===
RCS file: /cvs/src/src/gold/layout.cc,v
retrieving revision 1.196
diff -p -u -r1.196 layout.cc
--- layout.cc 24 May 2011 21:57:28 - 1.196
+++ layout.cc 25 May 2011 00:11:17 -
@@ -2192,9 +2192,8 @@ Layout::finalize(const Input_objects* in
: new Output_segment_headers(this->segment_list_));
// Lay out the file header.
- Output_file_header* file_header
-= new Output_file_header(target, symtab, segment_headers,
- parameters->options().entry());
+ Output_file_header* file_header = new Output_file_header(target, symtab,
+ segment_headers);
this->special_output_list_.push_back(file_header);
if (segment_headers != NULL)
Index: output.h
===
RCS file: /cvs/src/src/gold/output.h,v
retrieving revision 1.123
diff -p -u -r1.123 output.h
--- output.h 24 May 2011 23:31:07 - 1.123
+++ output.h 25 May 2011 00:11:19 -
@@ -566,8 +566,7 @@ class Output_file_header : public Output
public:
Output_file_header(const Target*,
const Symbol_table*,
- const Output_segment_headers*,
- const char* entry);
+ const Output_segment_headers*);
// Add information about the section headers. We lay out the ELF
// file header before we create the section headers.
@@ -614,7 +613,6 @@ class Output_file_header : public Output
const Output_segment_headers* segment_header_;
const Output_section_headers* section_header_;
const Output_section* shstrtab_;
- const char* entry_;
};
// Output sections are mainly comprised of input sections. However,
Index: output.cc
===
RCS file: /cvs/src/src/gold/output.cc,v
retrieving revision 1.146
diff -p -u -r1.146 output.cc
--- output.cc 24 May 2011 23:31:07 - 1.146
+++ output.cc 25 May 2011 00:11:21 -
@@ -425,14 +425,12 @@ Output_segment_headers::do_size() const
Output_file_header::Output_file_header(const Target* target,
const Symbol_table* symtab,
- const Output_segment_headers* osh,
- const char* entry)
+ const Output_segment_headers* osh)
: target_(target),
symtab_(symtab),
segment_header_(osh),
section_header_(NULL),
-shstrtab_(NULL),
-entry_(entry)
+shstrtab_(NULL)
{
Re: ld.gold: internal error in make_view, at fileread.cc:458
Arkadiusz Miskiewicz writes:
> uClibc does one test and checks exit status. For gold it causes internal
> error.
>
> binutils 2.21.51.0.9 on x86_64 linux.
>
> $ ld.gold --hash-style=gnu -o /dev/null -b binary /dev/null
> ld.gold: internal error in make_view, at fileread.cc:458
> zsh: exit 1 ld.gold --hash-style=gnu -o /dev/null -b binary /dev/null
>
> $ ld.bfd --hash-style=gnu -o /dev/null -b binary /dev/null
> ld.bfd: warning: cannot find entry symbol _start; not setting start address
Thanks for the bug report. Fixed with this patch, committed to both
mainline and the 2.21 branch.
Ian
2011-05-29 Ian Lance Taylor
* binary.cc (Binary_to_elf::sized_convert): Don't crash if the
binary input file is empty.
Index: binary.cc
===
RCS file: /cvs/src/src/gold/binary.cc,v
retrieving revision 1.4
diff -p -u -r1.4 binary.cc
--- binary.cc 7 Feb 2009 01:03:32 - 1.4
+++ binary.cc 29 May 2011 17:08:52 -
@@ -132,7 +132,11 @@ Binary_to_elf::sized_convert(const Task*
}
section_size_type filesize = convert_to_section_size_type(f.filesize());
- const unsigned char* fileview = f.get_view(0, 0, filesize, false, false);
+ const unsigned char* fileview;
+ if (filesize == 0)
+fileview = NULL;
+ else
+fileview = f.get_view(0, 0, filesize, false, false);
unsigned int align;
if (size == 32)
@@ -223,10 +227,13 @@ Binary_to_elf::sized_convert(const Task*
shstrtab.get_strtab_size(),
0, 0, 1, 0, &pout);
- memcpy(pout, fileview, filesize);
- pout += filesize;
- memset(pout, 0, aligned_filesize - filesize);
- pout += aligned_filesize - filesize;
+ if (filesize > 0)
+{
+ memcpy(pout, fileview, filesize);
+ pout += filesize;
+ memset(pout, 0, aligned_filesize - filesize);
+ pout += aligned_filesize - filesize;
+}
this->write_symbol("", &strtab, 0, 0, &pout);
this->write_symbol(start_symbol_name, &strtab, 0, 1,
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld.gold: internal error in make_view, at fileread.cc:458
"Witold Baryluk" writes: > Hmm, maybe this Bug have something with common with my gold report? > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620176 Unlikely. However, I just tried to recreate your bug with current mainline, and failed. It may have been fixed by some other change. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils
farshad ghassemi toosi writes: > I faced a very important problem about updating binutils, I wanted to use Qt > and opengl, I always got error so I search for that and I was advised to > update my binutils to the version of 2.19.16 or higher of course but I have > no idea what is Binutils, so I download the package but I don't know how to > update or install it in windows 7and even where is my current binutils now > in my pc , kindly I ask you to help me, it's very important for me. If you want binutils for Windows, you will do better to ask on a cygwin mailing list. See http://sourceware.org/cygwin/ for more information. They should have prebuilt releases for you. If you want to try to build it yourself, see the file binutils/README in the sources that you unpacked. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld.gold doesn't like if -L points to not a directory
Arkadiusz Miskiewicz writes:
> [arekm@ixion-pld ~]$ more ~/test/x.c
> int main() { return 0; }
> [arekm@ixion-pld ~]$ g++ -L/bin/sh ~/test/x.c
> /usr/bin/ld: error: /bin/sh: can not read directory: Not a directory
> collect2: ld returned 1 exit status
>
> but
>
> [arekm@ixion-pld ~]$ g++ -L/notexistant ~/test/x.c
> [arekm@ixion-pld ~]$
>
> (doesn't complain)
>
> $ ld --version
> GNU gold (Linux/GNU Binutils 2.21.52.0.2.20110610) 1.11
> [...]
>
> Note that ld.bfd has no trouble with -L pointing to not a directory (it
> simply
> ignores that fact).
>
> IMO gold should match ld.bfd behaviour and simply ignore not a directories.
Makes sense. Fixed like so. Committed to mainline.
Ian
2011-07-02 Ian Lance Taylor
* dirsearch.cc (Dir_cache::read_files): Ignore ENOTDIR errors.
Index: dirsearch.cc
===
RCS file: /cvs/src/src/gold/dirsearch.cc,v
retrieving revision 1.13
diff -u -p -r1.13 dirsearch.cc
--- dirsearch.cc 25 May 2011 06:15:28 - 1.13
+++ dirsearch.cc 3 Jul 2011 04:15:01 -
@@ -66,8 +66,9 @@ Dir_cache::read_files()
DIR* d = opendir(this->dirname_);
if (d == NULL)
{
- // We ignore directories which do not exist.
- if (errno != ENOENT)
+ // We ignore directories which do not exist or are actually file
+ // names.
+ if (errno != ENOENT && errno != ENOTDIR)
gold::gold_error(_("%s: can not read directory: %s"),
this->dirname_, strerror(errno));
return;
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug Report
S Akhtar writes: > 9. A description of error encountered: > > *Unhex: unknown Intel-hex record type: 0x04* > > *Unhex: line ‘:02040010EA’::* > > *From file ‘hello.hex’; Unrecognized record type* > A snapshot of the received error is attached for reference. > *Note: Please rename hello_exe to hello.exe (hello_exe attached)* Intel hex record type 0x04 is an extended linear address record. It's documented, e.g., here: http://www.keil.com/support/docs/1584.htm . This does not appear to be a bug in the GNU binutils. Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld gold stops looking for lib if it finds incompatible one first
Arkadiusz Miskiewicz writes: > Linux x86_64, 64 bit userspace > > binutils 2.21.53.0.2 > > bfd works fine > $ ld.bfd -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc > > but gold fails > $ ld.gold -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc > ld.gold: warning: skipping incompatible /usr/lib/libc.so while searching for c > ld.gold: error: cannot find -lc Can you send me the ulogd_BASE_sh.o file? Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: WindRes screws up RC output
Josh Ventura writes: > I filed a bug on the MinGW SourceForge page, and was sent here, or to > the vicinity of here. Problem is, windres.exe is generating invalid RC > output. Probably the best next step would be to file a bug report against the GNU binutils at http://sourceware.org/bugzilla/ . Ian ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
