* gcc binary format output @ 2006-07-12 1:27 Victor Roman Archidona 2006-07-12 4:39 ` Ian Lance Taylor 2006-07-13 12:45 ` gcc binary format output Kai Ruottu 0 siblings, 2 replies; 16+ messages in thread From: Victor Roman Archidona @ 2006-07-12 1:27 UTC (permalink / raw) To: gcc-help -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm porting FreeBSD to Gentoo for the Summer of Code project "Gentoo/FreeBSD for Amd64", and I need a little help about gcc binary output when compiling files. I compiled by hand GCC, and when I compile some file the output format is "UNIX - System V". I got this with `readelf -h program`. The problem is that I need the default binary output must be "UNIX - FreeBSD" and for now I can't fix it without help. BTW, If the output is "UNIX - System V" I can't run static compiled files, it shall be fixed changing the output behaviour. For example with the following small C program: #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { printf("it works!\n"); exit(EXIT_SUCCESS); } root@localhost ~ # gcc -static test.c -o test root@localhost ~ # readelf -h test | grep "OS/ABI" OS/ABI: UNIX - System V root@localhost ~ # ./test ELF binary type "0" not known. - -su: ./test: cannot execute binary file root@localhost ~ # Any input in this topic will be very apreciated. Thanks for all in advance, - -- Victor Roman Archidona -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEtFAPQ/ddYKMfqaARAt8ZAJ91m1qOK0ssqwkR73DGBrDnKG2wvQCff45s nCeS6o2yvI4LF6s0O/6Bb7U= =ELEo -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-12 1:27 gcc binary format output Victor Roman Archidona @ 2006-07-12 4:39 ` Ian Lance Taylor 2006-07-12 5:35 ` Victor Roman Archidona 2006-07-13 12:45 ` gcc binary format output Kai Ruottu 1 sibling, 1 reply; 16+ messages in thread From: Ian Lance Taylor @ 2006-07-12 4:39 UTC (permalink / raw) To: Victor Roman Archidona; +Cc: gcc-help Victor Roman Archidona <daijo@unixevil.info> writes: > I compiled by hand GCC, and when I compile some file the output format > is "UNIX - System V". When you compiled GCC yourself, what target did you use? To get FreeBSD labelled binaries, you should configure with something like --target=i386-freebsd You will also need to build the binutils with that --target option. Ian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-12 4:39 ` Ian Lance Taylor @ 2006-07-12 5:35 ` Victor Roman Archidona 2006-07-12 5:57 ` Ian Lance Taylor 0 siblings, 1 reply; 16+ messages in thread From: Victor Roman Archidona @ 2006-07-12 5:35 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc-help -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > Ian Lance Taylor escribió: When you compiled GCC yourself, what > target did you use? I didn't specified any target, my configure line was: ./configure --prefix=/usr - --bindir=/usr/x86_64-gentoo-freebsd6.1/gcc-bin/3.4.6 - --includedir=/usr/lib/gcc/x86_64-gentoo-freebsd6.1/3.4.6/include - --datadir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6 - --mandir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6/man - --infodir=/usr/share/gcc-data/x86_64-gentoo-freebsd6.1/3.4.6/info - --with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-freebsd6.1/3.4.6/include/g++-v3 - --host=x86_64-gentoo-freebsd6.1 --build=x86_64-gentoo-freebsd6.1 - --disable-altivec --disable-nls --with-system-zlib --disable-checking - --disable-werror --disable-libunwind-exceptions --enable-multilib - --disable-libgcj --enable-languages=c,c++ --enable-shared - --enable-threads=posix --enable-__cxa_atexit > To get FreeBSD labelled binaries, you should configure with > something like --target=i386-freebsd I used it with the error: "Please update *-*-freebsd* in gcc/config.gcc" so I don't touch it (the $target that I got with that was "i386-pc-freebsd"). Shall config.gcc sets the correct target? Reading it I saw the case "*-*-freebsd[6].*)" and my CHOST is "x86_64-gentoo-freebsd6.1" so it triggered the target with same results. > You will also need to build the binutils with that --target option. > My binutils has the following BFDs: elf64-x86-64 elf32-i386-freebsd coff-i386 efi-app-ia32, and emulations: elf_x86_64_fbsd elf_i386_fbsd elf_x86_64 elf_i386 Thanks in advance, - -- Victor Roman Archidona -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEtIoJQ/ddYKMfqaARAj3UAKCVYKDjOEaIWyPPKHuAsabpPpIbcACfYLMU ToRvWAldWTCvTkxgU/iSCs8= =dfcM -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-12 5:35 ` Victor Roman Archidona @ 2006-07-12 5:57 ` Ian Lance Taylor 2006-07-12 8:58 ` register usage Petar Bajic 0 siblings, 1 reply; 16+ messages in thread From: Ian Lance Taylor @ 2006-07-12 5:57 UTC (permalink / raw) To: Victor Roman Archidona; +Cc: gcc-help Victor Roman Archidona <daijo@unixevil.info> writes: > > You will also need to build the binutils with that --target option. > > > My binutils has the following BFDs: elf64-x86-64 elf32-i386-freebsd > coff-i386 efi-app-ia32, and emulations: elf_x86_64_fbsd elf_i386_fbsd > elf_x86_64 elf_i386 In that case, I don't know. Sorry. A FreeBSD developer might be able to help, or somebody else on this list. Ian ^ permalink raw reply [flat|nested] 16+ messages in thread
* register usage 2006-07-12 5:57 ` Ian Lance Taylor @ 2006-07-12 8:58 ` Petar Bajic 2006-07-12 12:48 ` Andrew Haley 0 siblings, 1 reply; 16+ messages in thread From: Petar Bajic @ 2006-07-12 8:58 UTC (permalink / raw) To: gcc-help I want to forbid compiler to use condition register for destination in movz instruction instruction (if r3 == 0, move r2 to r1) should look like this: movz r1, r2, r3 (r3 condition, r2 source, r1 destination register) but compiler generates this movz r3, r2, r3 and uses r3 further on. Wich is techincally ok, but I have this problem with overwritting condition and would like to save it. How do I tell compiler to generate different register for destination? Petar ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: register usage 2006-07-12 8:58 ` register usage Petar Bajic @ 2006-07-12 12:48 ` Andrew Haley 2006-07-13 12:33 ` Petar Bajic 0 siblings, 1 reply; 16+ messages in thread From: Andrew Haley @ 2006-07-12 12:48 UTC (permalink / raw) To: Petar Bajic; +Cc: gcc-help Petar Bajic writes: > I want to forbid compiler to use condition register for destination in movz > instruction > instruction (if r3 == 0, move r2 to r1) should look like this: > movz r1, r2, r3 (r3 condition, r2 source, r1 destination register) > but compiler generates this > movz r3, r2, r3 > and uses r3 further on. Wich is techincally ok, but I have this problem with > overwritting condition and would like to save it. > How do I tell compiler to generate different register for destination? Put the condition code register in a different class from the other registers. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: register usage 2006-07-12 12:48 ` Andrew Haley @ 2006-07-13 12:33 ` Petar Bajic 2006-07-13 12:45 ` Andrew Haley 0 siblings, 1 reply; 16+ messages in thread From: Petar Bajic @ 2006-07-13 12:33 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc-help ----- Original Message ----- From: "Andrew Haley" <aph@redhat.com> To: "Petar Bajic" <petar.bajic@micronasnit.com> Cc: <gcc-help@gcc.gnu.org> Sent: Wednesday, July 12, 2006 2:48 PM Subject: Re: register usage > Petar Bajic writes: > > I want to forbid compiler to use condition register for destination in > > movz > > instruction > > instruction (if r3 == 0, move r2 to r1) should look like this: > > movz r1, r2, r3 (r3 condition, r2 source, r1 destination register) > > but compiler generates this > > movz r3, r2, r3 > > and uses r3 further on. Wich is techincally ok, but I have this problem > > with > > overwritting condition and would like to save it. > > How do I tell compiler to generate different register for destination? > > Put the condition code register in a different class from the other > registers. > > Andrew. > For this, I had to make two new register classes (machine has 32 regs and basicly just one reg class GENERAL_REGS) I added two new classes: HI_REGS, and LO_REGS to "enum reg_classes" wich are lower and higher 16 regs of GENERAL_REGS. REG_CLASS_CONTENTS is expanded with { 0xffff0000 } and { 0x0000ffff } REG_CLASS_NAMES has two more names "HI_REGS" and "LO_REGS" in machine.c file I modified "reg_class_from_letter" making letter 'j' and 'k' return HI_REGS and LO_REGS in machine.md I finally wrote a rule that uses j and k regs to distinct input and output.... (define_insn "*movsicc_insn" [(set (match_operand:SI 0 "register_operand" "=j,j") (if_then_else:SI (match_operator 1 "comparison_operator" [(match_operand:SI 4 "register_operand" "=k,k") (const_int 0)]) (match_operand:SI 2 "register_operand" "=d,d") (match_operand:SI 3 "register_operand" "=d,d")))] "" "..." and the error is: ../../gcc/libgcc2.c:785: internal compiler error: in copy_to_mode_reg, at explow.c:581 what else do I have to do for this to work? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: register usage 2006-07-13 12:33 ` Petar Bajic @ 2006-07-13 12:45 ` Andrew Haley 0 siblings, 0 replies; 16+ messages in thread From: Andrew Haley @ 2006-07-13 12:45 UTC (permalink / raw) To: Petar Bajic; +Cc: gcc-help Petar Bajic writes: > > > For this, I had to make two new register classes (machine has 32 regs and > basicly just one reg class GENERAL_REGS) > I added two new classes: HI_REGS, and LO_REGS to "enum reg_classes" wich are > lower and higher 16 regs of GENERAL_REGS. > REG_CLASS_CONTENTS is expanded with { 0xffff0000 } and { 0x0000ffff } > REG_CLASS_NAMES has two more names "HI_REGS" and "LO_REGS" > > in machine.c file I modified "reg_class_from_letter" making letter 'j' and > 'k' return HI_REGS and LO_REGS > > in machine.md I finally wrote a rule that uses j and k regs to distinct > input and output.... > (define_insn "*movsicc_insn" > [(set (match_operand:SI 0 "register_operand" "=j,j") > (if_then_else:SI (match_operator 1 "comparison_operator" [(match_operand:SI > 4 "register_operand" "=k,k") (const_int 0)]) > (match_operand:SI 2 "register_operand" "=d,d") > (match_operand:SI 3 "register_operand" "=d,d")))] > "" > "..." > > and the error is: > ../../gcc/libgcc2.c:785: internal compiler error: in copy_to_mode_reg, at > explow.c:581 > > what else do I have to do for this to work? I would look in the debugger to see what copy_to_mode_reg was trying to do. I suspect you haven't defined a pattern to move into one of the register classes. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-12 1:27 gcc binary format output Victor Roman Archidona 2006-07-12 4:39 ` Ian Lance Taylor @ 2006-07-13 12:45 ` Kai Ruottu 2006-07-13 12:50 ` Andrew Haley 1 sibling, 1 reply; 16+ messages in thread From: Kai Ruottu @ 2006-07-13 12:45 UTC (permalink / raw) To: Victor Roman Archidona; +Cc: gcc-help Victor Roman Archidona wrote: > I compiled by hand GCC, and when I compile some file the output format > is "UNIX - System V". I got this with `readelf -h program`. > root@localhost ~ # gcc -static test.c -o test > root@localhost ~ # readelf -h test | grep "OS/ABI" > OS/ABI: UNIX - System V I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1' and got just the same result: kai@Dell:/data1/home/kai-old/test/tprintf> readelf -h tst_freebsd64.x | grep OS/ABI OS/ABI: UNIX - System V while the binaries in the FreeBSD6.1/amd64 install CD like it's 'gcc' and 'libc.so.6' had: kai@Dell:/media/cdrecorder/usr/bin> readelf -h gcc | grep OS/ABI OS/ABI: UNIX - FreeBSD kai@Dell:/media/cdrecorder/lib> readelf -h libc.so.6 | grep OS/ABI OS/ABI: UNIX - FreeBSD So the executables produced have this wrong type... I would guess GCC or the GNU 'as' should be sued for this thing because: kai@Dell:/data1/home/kai-old/test/tprintf> readelf -h tst_freebsd64.o | grep OS/ABI OS/ABI: UNIX - System V The binutils I used were the latest '2.17.50.0.2' Linux ones from: ftp.kernel.org/pub/linux/devel/binutils The GCC version tried was '4.0.3'... I will try gcc-4.1.1 still but getting this bug fixed also in gcc-4.0.x could be nice. Anyone knowing this much about binutils and GCC, which config etc. setting could cause the 'bad magic'? The right FreeBSD bins have: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 but the wrong ones have: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-13 12:45 ` gcc binary format output Kai Ruottu @ 2006-07-13 12:50 ` Andrew Haley 2006-07-13 16:42 ` Kai Ruottu 0 siblings, 1 reply; 16+ messages in thread From: Andrew Haley @ 2006-07-13 12:50 UTC (permalink / raw) To: Kai Ruottu; +Cc: gcc-help Kai Ruottu writes: > Victor Roman Archidona wrote: > > > I compiled by hand GCC, and when I compile some file the output format > > is "UNIX - System V". I got this with `readelf -h program`. > > root@localhost ~ # gcc -static test.c -o test > > root@localhost ~ # readelf -h test | grep "OS/ABI" > > OS/ABI: UNIX - System V > > I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1' > and got just the same result: This is way off-topic. gcc produces assembly code, not binaries. You should be talking to a binutils list. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-13 12:50 ` Andrew Haley @ 2006-07-13 16:42 ` Kai Ruottu 2006-07-15 14:01 ` Victor Roman Archidona 0 siblings, 1 reply; 16+ messages in thread From: Kai Ruottu @ 2006-07-13 16:42 UTC (permalink / raw) To: gcc-help Andrew Haley wrotes: > Kai Ruottu writes: > > Victor Roman Archidona wrote: > > > > > I compiled by hand GCC, and when I compile some file the output format > > > is "UNIX - System V". I got this with `readelf -h program`. > > > > I tried a crosscompiler from 'i686-linux-gnu' to the 'x86_64-freebsd6.1' > > and got just the same result: > > This is way off-topic. gcc produces assembly code, not binaries. You > should be talking to a binutils list. > I myself haven't joined to the binutils list, only to this and the gcc list. And generally did my try 'just for a fun' in this specific case, but Victor Roman Archidona could have some motives to get this thing working in his own project... Anyhow the fix being told after it was invented could be nice. At least to me if my message gave any clues for where the bug could be :-) Otherwise I will stop all the further build tries and maybe can give misinformation about the binutils/GCC situation with FreeBSD/x86_64 when not being informed that the bug was fixed already... BTW, for those who (still) don't know "how to build a crosscompiler" (like those who write the GNU docs :-) here is my usual method : For my crosscompiler to 'x86_64-freebsd6.1', I first built and installed the binutils-2.17.50.0.2 for this target. Then I installed the target C library from the FreeBSD 6.1/amd64 install CDs and finally built gcc-4.0.3 from its sources. This is the method I have used to, and there should be some very good reasons to get me learning how on earth the C libraries for FreeBSD could be built from absolute scratch... The only problem during the build, for which I should have asked comments here but forgot to do that, was that the target headers, specifically the '<machine/_types.h>', already defined the '__gnuc_va_list' but the 'gcc-4.0.3/gcc/sys-types.h' tried to define this again. My quick-and-dirty fix was to wrap the 'gcc-4.0.3/gcc/sys-types.h' with the same: #ifndef __GNUC_VA_LIST #define __GNUC_VA_LIST <the '__gnuc_va_list' typedef> #endif wrapper as this FreeBSD 6.1 header had. Maybe the right fix could have been to redefine this (gcc-4.0.3-wise) in the 'gcc/sys-types.h'. This clash happened when the new 'xgcc' & Co. tried to compile the '$build/gcc/SYSCALLS.c'... In any case my build method had not much to do with the current GNU site 'advices', I just did the build in the same way I have done a GCC build during the last 10 years and during the last 1000 builds.... I can quite well agree with Andrew about binutils and C library things not belonging to GCC in any way, but how on earth this fact could be told to the GNU docs writers? The 'http://gcc.gnu.org/install/prerequisites.html' doesn't mention anything about the C library and (almost) claims the binutils being something 'optional'. For the crosscompiler builders both these are obligatory prerequisites and in most cases the target C library already exists in the target system itself. The: 'http://gcc.gnu.org/install/build.html' tells instead : Build runtime libraries using the stage3 compiler from the previous step. for the native case and: * Build the compiler (single stage only). * Build runtime libraries using the compiler from the previous step. for the cross case. But whether a newbie understands what these 'runtime libraries' are, is quite unclear. After producing those 1000 and much more GCCs, neither do I understand what these mean. Should the native GCC builder try to build the C libraries after the GCC build or what? And the crosscompiler builder should do the same? In the embedded target cases this really happens, people like me usually produce the C library (newlib) after getting GCC ('gcc', 'libiberty', 'libstdc++',...) built. The "single stage only" is some sanity but as we have seen recently on this list : ------------------ clip -------------------------- Raphael Zulliger wrote: > Building a crosscompiler should be done as described in the different docs/wikis/howtos. ------------------ clip -------------------------- all kind of "how-to"s and "wiki"s try to use the famous "code red" for the new 'recruits': http://en.wikipedia.org/wiki/A_Few_Good_Men in their first crosscompiler builds, "a form of hazing unofficially sanctioned by higher-ranking officers designed to make soldiers pay attention to orders and rules". To their own "orders and rules", not to the GNU rules like this "single stage only" :-( As an corporal (now in reserves) in the Finnish recruit army, Signal Corps, I didn't like using that 'code red' into those recruits. And don't understand why anyone likes using it nowadays for the newbies in GCC building, with their self-invented multi-stage builds others "should use" (like Raphael writes). Not funny at all but really sad... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-13 16:42 ` Kai Ruottu @ 2006-07-15 14:01 ` Victor Roman Archidona 2006-07-17 19:13 ` Kai Ruottu 0 siblings, 1 reply; 16+ messages in thread From: Victor Roman Archidona @ 2006-07-15 14:01 UTC (permalink / raw) To: Kai Ruottu; +Cc: gcc-help -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Kai Ruottu escribió: for where the bug could be :-) Otherwise I > will stop all the further build tries and maybe can give > misinformation about the binutils/GCC situation with FreeBSD/x86_64 > when not being informed that the bug was fixed already... Thanks for your feedback Kai. In the binutils mailing list has been sent a patch that fixes the problem. The URL for anyone interested in it is: http://www.sourceware.org/ml/binutils/2006-07/msg00192.html An example of binutils-2.17 with patch applied: root@localhost ~ # gcc -static test.c -o test root@localhost ~ # ./test it works! root@localhost ~ # file test test: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.1, statically linked, for FreeBSD 6.1, not stripped root@localhost ~ # Regards, - -- Victor Roman Archidona -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEuPUoQ/ddYKMfqaARAuOvAKCFyN7MtdW/ZdnpGMTeecLb4B1XCwCgj0iV MyMxa/7cTWZVLTpAnlD5yJY= =9Rru -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-15 14:01 ` Victor Roman Archidona @ 2006-07-17 19:13 ` Kai Ruottu 2006-07-18 12:24 ` Kai Ruottu 0 siblings, 1 reply; 16+ messages in thread From: Kai Ruottu @ 2006-07-17 19:13 UTC (permalink / raw) To: Victor Roman Archidona; +Cc: gcc-help Victor Roman Archidona kirjoitti: > Thanks for your feedback Kai. In the binutils mailing list has been > sent a patch that fixes the problem. The URL for anyone interested in > it is: > > http://www.sourceware.org/ml/binutils/2006-07/msg00192.html > Thanks to you too! I tried also a crosscompiler for the 32-bit FreeBSD 6.1/i386 and checked if the 'bfd/config.bfd' had anything special for this target, different from the Linux/i386 for instance. And it definitely had, and this special 'bfd_elf32_i386_freebsd_vec' not listed for the 'x86_64-*-freebsd*'... Adding that maybe fixed the 32-bit support with '-m32' but not the 64-bit. So I already guessed that something should still be done to implement that missing 'bfd_elf64_x86_64_freebsd_vec'. The 'alpha' port for FreeBSD had its own special 'elf64_alpha_freebsd_vec' already... Why the official GNU binutils don't have this support for the FreeBSD/x86_64 (I checked the '060713' snapshots too), was of course weird. Anyway getting it "locally" should now succeed... > An example of binutils-2.17 with patch applied: > > root@localhost ~ # gcc -static test.c -o test > root@localhost ~ # ./test > it works! > root@localhost ~ # file test > test: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for > FreeBSD 6.1, statically linked, for FreeBSD 6.1, not stripped > root@localhost ~ # > The 'i586-freebsd6.1' target toolchains (gcc-3.4.6, 4.0.3 and 4.1.1) I built seemed to produce quite "right" executables, lets see what the 'x86_64-freebsd6.1' ones will do now. Of course reproducing all their 'libgcc_s.so.1's and 'libstdc++.so's must be done... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-17 19:13 ` Kai Ruottu @ 2006-07-18 12:24 ` Kai Ruottu 2006-07-18 14:12 ` Victor Roman Archidona 2006-07-18 18:26 ` Mike Frysinger 0 siblings, 2 replies; 16+ messages in thread From: Kai Ruottu @ 2006-07-18 12:24 UTC (permalink / raw) Cc: Victor Roman Archidona, gcc-help, binutils Kai Ruottu kirjoitti: > Victor Roman Archidona kirjoitti: >> Thanks for your feedback Kai. In the binutils mailing list has been >> sent a patch that fixes the problem. The URL for anyone interested in >> it is: >> >> http://www.sourceware.org/ml/binutils/2006-07/msg00192.html >> > lets see what the 'x86_64-freebsd6.1' ones will do now. The given patches weren't enough :-( The resulted GNU linker complained about not finding the output format etc. A quick "how these things were done in 'alpha', 'i386' etc." comparison revealed that also the 'ld/emulparams' directory required the following patch in the current 'binutils-2.17.50.0.3' : ---------------- clip ---------------------------- *** elf_x86_64_fbsd.sh.orig Thu Mar 7 21:52:39 2002 --- elf_x86_64_fbsd.sh Tue Jul 18 15:06:58 2006 *************** *** 1,2 **** --- 1,3 ---- . ${srcdir}/emulparams/elf_x86_64.sh . ${srcdir}/emulparams/elf_fbsd.sh + OUTPUT_FORMAT="elf64-x86-64-freebsd" ---------------- clip ---------------------------- After adding this the produced binutils gave right labeled executables and more importantly the crosscompilers to the 'x86_64-freebsd6.1' target could be built, giving seemingly OK shared libraries with the following: kai@Dell:/data1/home/src/gcc-4.0.3/build/gcc> readelf -h libgcc_s.so.1 ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - FreeBSD ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 output got via the 'readelf -h'... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-18 12:24 ` Kai Ruottu @ 2006-07-18 14:12 ` Victor Roman Archidona 2006-07-18 18:26 ` Mike Frysinger 1 sibling, 0 replies; 16+ messages in thread From: Victor Roman Archidona @ 2006-07-18 14:12 UTC (permalink / raw) To: Kai Ruottu, gcc-help -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The given patches weren't enough :-( The resulted GNU linker > complained about not finding the output format etc. A quick "how > these things were done in 'alpha', 'i386' etc." comparison revealed > that also the 'ld/emulparams' directory required the following > patch in the current 'binutils-2.17.50.0.3' : > I sent that yesterday to binutils mailing list, the message with the modified patch is the following: http://sources.redhat.com/ml/binutils/2006-07/msg00220.html Regards, - -- Victor Roman Archidona -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEvOwdQ/ddYKMfqaARAgO9AKCD8fUwNh0AK5ZlVs2+9QMpJ3q1yQCfc1Va W3G7meCtqES2NUtTJu+lFtk= =il1C -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: gcc binary format output 2006-07-18 12:24 ` Kai Ruottu 2006-07-18 14:12 ` Victor Roman Archidona @ 2006-07-18 18:26 ` Mike Frysinger 1 sibling, 0 replies; 16+ messages in thread From: Mike Frysinger @ 2006-07-18 18:26 UTC (permalink / raw) To: binutils; +Cc: Kai Ruottu, Victor Roman Archidona, gcc-help [-- Attachment #1: Type: text/plain, Size: 521 bytes --] On Tuesday 18 July 2006 08:37, Kai Ruottu wrote: > The given patches weren't enough :-( The resulted GNU linker complained > about not finding the output format etc. A quick "how these things were > done > in 'alpha', 'i386' etc." comparison revealed that also the 'ld/emulparams' > directory required the following patch in the current > 'binutils-2.17.50.0.3' : Victor already posted this fix ... best if you follow the new thread on the binutils list rather than continuing this cross-posted one -mike [-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-07-18 18:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-07-12 1:27 gcc binary format output Victor Roman Archidona 2006-07-12 4:39 ` Ian Lance Taylor 2006-07-12 5:35 ` Victor Roman Archidona 2006-07-12 5:57 ` Ian Lance Taylor 2006-07-12 8:58 ` register usage Petar Bajic 2006-07-12 12:48 ` Andrew Haley 2006-07-13 12:33 ` Petar Bajic 2006-07-13 12:45 ` Andrew Haley 2006-07-13 12:45 ` gcc binary format output Kai Ruottu 2006-07-13 12:50 ` Andrew Haley 2006-07-13 16:42 ` Kai Ruottu 2006-07-15 14:01 ` Victor Roman Archidona 2006-07-17 19:13 ` Kai Ruottu 2006-07-18 12:24 ` Kai Ruottu 2006-07-18 14:12 ` Victor Roman Archidona 2006-07-18 18:26 ` Mike Frysinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).