From kk@ddeorg.soft.net Tue Jan 5 03:17:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Tue, 05 Jan 1999 03:17:00 -0000 Subject: Problems with the GNU linker.... Message-ID: <199901051117.QAA11458@bombay.ddeorg.soft.net> Hi all, I have been using the egcs-2.91.57 19980901 (egcs-1.1 release) gcc and g++ compilers and all the other tools on my system which is MIPS (R4000) based running the SVR4.2 UNIX on the Supermax Business Server for a few months now and they seem to work fine. How ever I am still not able to use the GNU linker. For making the egcs port I used the native linker ( from the EPC - Edinberg portable compiler and Tools) and it took me 6 months !!. I am not able to generate the dynamic libraries. The GNU assembler (gas) and the native ld pair does not seem to work. So again I decided to try making the latest ld from the most recent snapshots from ftp.cygnus.com/private/gas. For getting the ld compiled I used the following in the ld/configure.tgt as before. mips-*-sysv*) targ_emul=elf32bsmip ;; Got the ld compiled. But when I try to compile the famous Hello world program I get --------------- Output of test -------------------------------------------- ../test Hello World dynamic linker: ./test: unidentifiable procedure reference (address = 0x40062cd8) Killed ----------------------------------------------------------------------------- - I tried to use the readelf utility , but got no clues. The ldd -d ./test shows that that the C libraries are dynamically loaded. Is the support for the GNU linker on most of the MIPS platforms still not complete. ? Is this a known problem ?. Please help me. Are there any patches available ?. Thanks a lot for any help received. With best regards Koundinya From ian@cygnus.com Tue Jan 5 05:57:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 05 Jan 1999 05:57:00 -0000 Subject: Problems with the GNU linker.... References: <199901051117.QAA11458@bombay.ddeorg.soft.net> Message-ID: <199901051340.IAA01663@subrogation.cygnus.com> Date: Tue, 05 Jan 1999 16:47:04 +0530 From: "Koundinya.K" I have been using the egcs-2.91.57 19980901 (egcs-1.1 release) gcc and g++ compilers and all the other tools on my system which is MIPS (R4000) based running the SVR4.2 UNIX on the Supermax Business Server for a few months now and they seem to work fine. How ever I am still not able to use the GNU linker. For making the egcs port I used the native linker ( from the EPC - Edinberg portable compiler and Tools) and it took me 6 months !!. I am not able to generate the dynamic libraries. The GNU assembler (gas) and the native ld pair does not seem to work. The GNU linker does not fully support shared libraries on MIPS ELF platforms. It seems to work well enough for MIPS GNU/Linux; I don't know the details, and I don't know if all the patches have been integrated into the mainline sources. Somebody is working on improving the Irix 6 support, which will hopefully include improvements for the general MIPS ELF support. I don't know why gas does not work with the native linker. That does work on Irix. It isn't likely to work if you configure gas for mips-sysv, as that appears to generate ECOFF. Make sure you configure for mips-elf or mips-linux-gnu, or fix the gas/configure.in file and regenerate gas/configure. --------------- Output of test -------------------------------------------- ../test Hello World dynamic linker: ./test: unidentifiable procedure reference (address = 0x40062cd8) Killed ----------------------------------------------------------------------------- - I tried to use the readelf utility , but got no clues. Try changing the definition of SGI_COMPAT in bfd/elf32-mips.c from 1 to 0. By default the linker will generate some form of the Irix quickstart relocs. However, you should expect to run into other problems, particularly if you try to generate shared libraries yourself. Ian From hbrunert@ultre.com Wed Jan 6 13:40:00 1999 From: hbrunert@ultre.com (Brunert, Hugo) Date: Wed, 06 Jan 1999 13:40:00 -0000 Subject: Gnu 68K assembler (actually coldfire 5307) Message-ID: <9097946A6AB9D111A8C900A0C92591F0198714@ultre_nt1.li.net> Hi. I have just taken on a job to work with the Gnu utilities, targeted for the 68K. I have been doing 68K assembly work for over 15 years, and I am familiar with 6 different 68K assemblers. I have read the GNU assembler document by Dean Elsner, Jay Fenlason & friends dated January 1994, and find that I have not yet been able to create an error free listing of a program I wrote. I would like to get in contact with someone who would be nice enough to answer a few questions I have regarding the GNU assembler. I would appreciate any light you can shine on this subject. Thank you very much in advance! Hugo From hjl@lucon.org Thu Jan 7 12:16:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 07 Jan 1999 12:16:00 -0000 Subject: Does anyone have diffs-weekly-981215.gz? Message-ID: Hi, Does anyone have diffs-weekly-981215.gz for gas snapshot? I don't want to download 5MB file over a modem. Thanks. -- H.J. Lu (hjl@gnu.org) From ralf@uni-koblenz.de Sat Jan 9 16:32:00 1999 From: ralf@uni-koblenz.de (ralf@uni-koblenz.de) Date: Sat, 09 Jan 1999 16:32:00 -0000 Subject: Problems with the GNU linker.... References: <199901051117.QAA11458@bombay.ddeorg.soft.net> <199901051340.IAA01663@subrogation.cygnus.com> <199901051340.IAA01663@subrogation.cygnus.com> Message-ID: <19990110011359.D3254@uni-koblenz.de> On Tue, Jan 05, 1999 at 08:40:55AM -0500, Ian Lance Taylor wrote: > The GNU linker does not fully support shared libraries on MIPS ELF > platforms. It seems to work well enough for MIPS GNU/Linux; I don't > know the details, and I don't know if all the patches have been > integrated into the mainline sources. I've got patches which fix the handling of .reginfo sections in binutils 2.9.1, the handling of %hi, %HI and %lo and a few bfd coredumps for Linux/MIPS. The two open bugs are symbol versioning which as I understand elf32-mips.c will require rewriting the .got handling. Right now the attempt to use symbol versioning on MIPS will result in core dumps and large amounts of assertion failures. The other open bug is that ld emits a couple of apparently bogus warnings about symbols changing their types when linking dynamic programs. Ralf From gaius@glam.ac.uk Mon Jan 11 08:47:00 1999 From: gaius@glam.ac.uk (gaius@glam.ac.uk) Date: Mon, 11 Jan 1999 08:47:00 -0000 Subject: {Many thanks for the binutils package} References: <95091916021341@glam.ac.uk> Message-ID: re: an email conversation from 5 Oct 1995 !! Hi Ken, it has been over three years since we last communicated about binutils. > From: Ken Raeburn > Date: Thu, 5 Oct 1995 20:42:53 -0400 > I'd rather wait on including new non-public machines (abstract or real) > until the machine is publicly available. Having a gcc port incorporated > and released would also be a big argument in favor of including the > binutils port. (Is your Modula-2 compiler based on the gcc back end?) The Modula-2 compiler has been publically available for over three years now, sadly the back end is not based on gcc though. The Modula-2 compiler, ismene simulator (abstract machine) is all GPL'd. The compiler generates ismene code, and i*86 code with pentium optimizations. I've signed the GNU copyright assignment form and posted them three years ago. Would you like me to do this again as some of the file names might have changed? I've uploaded the compiler and abstract machine to tsx-11.mit.edu, redhat.com and also made them publically available from my machine. (Well this will be done by 15:00 GMT) Basically I have (carefully) ported the binutils to my abstract machine, it was called "smp" which you rightly suggested was rather too generic. I've now called it "is32" (ismene processor 32 bit). I've did the port for binutils 2.5.2 and binutils-2.9.1.0.4 and the equivalent GDB releases. But as Computer Scientists hate repeating work (!) I took your advice and have integrated my very minor additions to the snapshot of 01 04 99 (last Monday the 4th Jan 99) and offer the changes to be included in the official binutils release. The ismene abstract machine is actually a multiprocessor discrete event simulator which I wrote for my PhD 10 years ago. I've been working on it since and it now operates with GDB and has a lesstif GUI. What is rather fun is that the abstract machine can be told to run backwards.. so one can find out where you came from (I confess I got quite a buz from seeing the source line pointer go in reverse, and printing out old variable values). Ismene is really meant to model software costs, runtime prediction of multiprocessor microkernels etc, an ongoing research project - and we also use it for teaching at the Univ. of Glamorgan. So what I'm trying to say is that quite a few people might use it. (Although I accept tiny compared to the i*86 ports..) > Does it have any more specific name than "smp"? That sounds very > generic.... > The diffs in your message look straightforward and reasonable, though I > haven't looked at the contents of the tar file. hopefully this is still the case :-) > The configuration handling of some directories has changed, so > integrating your changes into a snapshot would help us quite a bit. thats ok. > Ken many thanks for all your efforts at GNU and Cygnus Support, you are changing the software world for the better of mankind. I'm a great fan of GPL. Below here are two sections: (i) diffs which allow is32 to be configured (ii) extra files required by is32 configuration cheers Gaius --- Gaius Mulley University of Glamorgan gaius@glam.ac.uk Tel: 01443 482279 "I previously had IE4/NT4 on the same box and by comparison the combination of Linux/Nagivator ran at least 30-40% faster when rendering simple HTML + graphics", Josh Cohen, Microsoft (8/98) Here are the diffs generated with diff -r -c diff -r -c gas-990104.orig/bfd/aoutx.h gas-990104/bfd/aoutx.h *** gas-990104.orig/bfd/aoutx.h Mon Jan 4 09:12:39 1999 --- gas-990104/bfd/aoutx.h Wed Jan 6 20:56:18 1999 *************** *** 764,769 **** --- 764,770 ---- /* FIXME: These should be MIPS3 or MIPS4. */ arch_flags = M_MIPS2; break; + default: arch_flags = M_UNKNOWN; break; *************** *** 778,783 **** --- 779,787 ---- default: arch_flags = M_UNKNOWN; break; } break; + + case bfd_arch_is32: + if (machine == 0) arch_flags = M_IS32; break; case bfd_arch_vax: *unknown = false; diff -r -c gas-990104.orig/bfd/archures.c gas-990104/bfd/archures.c *** gas-990104.orig/bfd/archures.c Mon Jan 4 09:17:06 1999 --- gas-990104/bfd/archures.c Wed Jan 6 18:29:22 1999 *************** *** 231,236 **** --- 231,237 ---- extern const bfd_arch_info_type bfd_i386_arch; extern const bfd_arch_info_type bfd_i860_arch; extern const bfd_arch_info_type bfd_i960_arch; + extern const bfd_arch_info_type bfd_is32_arch; extern const bfd_arch_info_type bfd_m32r_arch; extern const bfd_arch_info_type bfd_m68k_arch; extern const bfd_arch_info_type bfd_m88k_arch; *************** *** 267,272 **** --- 268,274 ---- &bfd_i386_arch, &bfd_i860_arch, &bfd_i960_arch, + &bfd_is32_arch, &bfd_m32r_arch, &bfd_m68k_arch, &bfd_m88k_arch, diff -r -c gas-990104.orig/bfd/bfd-in2.h gas-990104/bfd/bfd-in2.h *** gas-990104.orig/bfd/bfd-in2.h Mon Jan 4 09:17:10 1999 --- gas-990104/bfd/bfd-in2.h Wed Jan 6 18:32:22 1999 *************** *** 1270,1275 **** --- 1270,1276 ---- bfd_arch_we32k, /* AT&T WE32xxx */ bfd_arch_tahoe, /* CCI/Harris Tahoe */ bfd_arch_i860, /* Intel 860 */ + bfd_arch_is32, /* Ismene abstract machine */ bfd_arch_romp, /* IBM ROMP PC/RT */ bfd_arch_alliant, /* Alliant */ bfd_arch_convex, /* Convex */ Only in gas-990104/bfd: bfd-in3.h diff -r -c gas-990104.orig/bfd/coffcode.h gas-990104/bfd/coffcode.h *** gas-990104.orig/bfd/coffcode.h Mon Jan 4 09:16:55 1999 --- gas-990104/bfd/coffcode.h Wed Jan 6 18:33:22 1999 *************** *** 1620,1625 **** --- 1620,1631 ---- break; #endif + #ifdef IS32MAGIC + case bfd_arch_is32: + arch = bfd_arch_is32; + break; + #endif + default: /* Unreadable input file type */ arch = bfd_arch_obscure; diff -r -c gas-990104.orig/bfd/config.bfd gas-990104/bfd/config.bfd *** gas-990104.orig/bfd/config.bfd Mon Jan 4 09:17:11 1999 --- gas-990104/bfd/config.bfd Wed Jan 6 18:34:28 1999 *************** *** 288,293 **** --- 288,298 ---- targ_underscore=yes ;; + is32-*-*) + targ_defvec=is32_aout_vec + targ_underscore=yes + ;; + m32r-*-*) targ_defvec=bfd_elf32_m32r_vec ;; Only in gas-990104/bfd: config.h diff -r -c gas-990104.orig/bfd/configure gas-990104/bfd/configure *** gas-990104.orig/bfd/configure Mon Jan 4 09:27:11 1999 --- gas-990104/bfd/configure Wed Jan 6 18:37:44 1999 *************** *** 5093,5098 **** --- 5093,5099 ---- icoff_big_vec) tb="$tb coff-i960.lo cofflink.lo" ;; icoff_little_vec) tb="$tb coff-i960.lo cofflink.lo" ;; ieee_vec) tb="$tb ieee.lo" ;; + is32_aout_vec) tb="$tb is32aout.lo aout32.lo stab-syms.lo" ;; m68kcoff_vec) tb="$tb coff-m68k.lo cofflink.lo" ;; m68kcoffun_vec) tb="$tb coff-u68k.lo coff-m68k.lo cofflink.lo" ;; m68klinux_vec) tb="$tb m68klinux.lo aout32.lo" ;; diff -r -c gas-990104.orig/bfd/configure.in gas-990104/bfd/configure.in *** gas-990104.orig/bfd/configure.in Mon Jan 4 09:27:11 1999 --- gas-990104/bfd/configure.in Wed Jan 6 18:38:18 1999 *************** *** 494,499 **** --- 494,500 ---- icoff_big_vec) tb="$tb coff-i960.lo cofflink.lo" ;; icoff_little_vec) tb="$tb coff-i960.lo cofflink.lo" ;; ieee_vec) tb="$tb ieee.lo" ;; + is32_aout_vec) tb="$tb is32aout.lo aout32.lo stab-syms.lo" ;; m68kcoff_vec) tb="$tb coff-m68k.lo cofflink.lo" ;; m68kcoffun_vec) tb="$tb coff-u68k.lo coff-m68k.lo cofflink.lo" ;; m68klinux_vec) tb="$tb m68klinux.lo aout32.lo" ;; Only in gas-990104/bfd: cpu-is32.c Only in gas-990104/bfd: is32aout.c diff -r -c gas-990104.orig/bfd/libaout.h gas-990104/bfd/libaout.h *** gas-990104.orig/bfd/libaout.h Mon Jan 4 09:12:59 1999 --- gas-990104/bfd/libaout.h Wed Jan 6 18:39:44 1999 *************** *** 243,248 **** --- 243,249 ---- M_HPUX = (0x20c % 256), /* HP 200/300 HPUX binary */ M_SPARCLET_5 = 211, /* 0xd3, reserved */ M_SPARCLET_6 = 227, /* 0xe3, reserved */ + M_IS32 = 240, /* Ismene processor */ /* M_SPARCLET_7 = 243 / * 0xf3, reserved */ M_SPARCLITE_LE = 243 }; diff -r -c gas-990104.orig/bfd/targets.c gas-990104/bfd/targets.c *** gas-990104.orig/bfd/targets.c Mon Jan 4 09:16:54 1999 --- gas-990104/bfd/targets.c Wed Jan 6 18:40:40 1999 *************** *** 554,559 **** --- 554,560 ---- extern const bfd_target icoff_big_vec; extern const bfd_target icoff_little_vec; extern const bfd_target ieee_vec; + extern const bfd_target is32_aout_vec; extern const bfd_target m68kaux_coff_vec; extern const bfd_target m68kcoff_vec; extern const bfd_target m68kcoffun_vec; Only in gas-990104/config: mh-is32 diff -r -c gas-990104.orig/config.sub gas-990104/config.sub *** gas-990104.orig/config.sub Mon Jan 4 09:26:51 1999 --- gas-990104/config.sub Wed Jan 6 18:41:40 1999 *************** *** 187,193 **** basic_machine=$basic_machine-unknown ;; m88110 | m680[012346]0 | m683?2 | m68360 | m5200 | z8k | v70 \ ! | h8500 | w65 | fr30) # CYGNUS LOCAL basic_machine=$basic_machine-unknown ;; thumb) --- 187,193 ---- basic_machine=$basic_machine-unknown ;; m88110 | m680[012346]0 | m683?2 | m68360 | m5200 | z8k | v70 \ ! | h8500 | w65 | fr30 | is32) # CYGNUS LOCAL basic_machine=$basic_machine-unknown ;; thumb) Only in gas-990104/gas/config: tc-is32.c Only in gas-990104/gas/config: tc-is32.h diff -r -c gas-990104.orig/gas/configure gas-990104/gas/configure *** gas-990104.orig/gas/configure Mon Jan 4 09:27:14 1999 --- gas-990104/gas/configure Wed Jan 6 20:46:30 1999 *************** *** 1707,1712 **** --- 1707,1714 ---- i960-*-vxworks5.*) fmt=coff em=ic960 ;; i960-*-vxworks*) fmt=bout ;; + is32-*-*) fmt=aout bfd_gas=yes ;; + m32r-*-*) fmt=elf bfd_gas=yes ;; m68k-*-vxworks* | m68k-ericsson-ose | m68k-*-sunos*) diff -r -c gas-990104.orig/gas/configure.in gas-990104/gas/configure.in *** gas-990104.orig/gas/configure.in Mon Jan 4 09:27:13 1999 --- gas-990104/gas/configure.in Wed Jan 6 20:41:23 1999 *************** *** 195,200 **** --- 195,202 ---- i960-*-vxworks5.*) fmt=coff em=ic960 ;; i960-*-vxworks*) fmt=bout ;; + is32-*-*) fmt=aout em=is32 bfd_gas=yes ;; + m32r-*-*) fmt=elf bfd_gas=yes ;; m68k-*-vxworks* | m68k-ericsson-ose | m68k-*-sunos*) diff -r -c gas-990104.orig/include/dis-asm.h gas-990104/include/dis-asm.h *** gas-990104.orig/include/dis-asm.h Mon Jan 4 09:23:21 1999 --- gas-990104/include/dis-asm.h Wed Jan 6 19:37:08 1999 *************** *** 144,149 **** --- 144,150 ---- extern int print_insn_big_mips PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_little_mips PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_i386 PARAMS ((bfd_vma, disassemble_info*)); + extern int print_insn_is32 PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_m68k PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_z8001 PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_z8002 PARAMS ((bfd_vma, disassemble_info*)); diff -r -c gas-990104.orig/include/elf/common.h gas-990104/include/elf/common.h *** gas-990104.orig/include/elf/common.h Mon Jan 4 09:13:35 1999 --- gas-990104/include/elf/common.h Wed Jan 6 18:54:01 1999 *************** *** 97,102 **** --- 97,103 ---- #define EM_OLD_ALPHA 41 /* Digital Alpha */ #define EM_SH 42 /* Hitachi SH */ #define EM_SPARCV9 43 /* SPARC v9 64-bit */ + #define EM_IS32 0x8253 /* IS32 ismene abstract machine (followed note below) */ /* If it is necessary to assign new unofficial EM_* values, please pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the chances of collision Only in gas-990104/include/opcode: is32.h diff -r -c gas-990104.orig/intl/config.h gas-990104/intl/config.h *** gas-990104.orig/intl/config.h Mon Jan 4 09:29:49 1999 --- gas-990104/intl/config.h Wed Jan 6 19:05:38 1999 *************** *** 42,48 **** /* #undef STACK_DIRECTION */ /* Define if you have the ANSI C header files. */ ! /* #undef STDC_HEADERS */ /* Define to 1 if NLS is requested. */ #define ENABLE_NLS 1 --- 42,48 ---- /* #undef STACK_DIRECTION */ /* Define if you have the ANSI C header files. */ ! #define STDC_HEADERS 1 /* Define to 1 if NLS is requested. */ #define ENABLE_NLS 1 *************** *** 51,72 **** /* #undef HAVE_CATGETS */ /* Define as 1 if you have gettext and don't want to use GNU gettext. */ ! /* #undef HAVE_GETTEXT */ /* Define as 1 if you have the stpcpy function. */ ! /* #undef HAVE_STPCPY */ /* Define if your locale.h file contains LC_MESSAGES. */ #define HAVE_LC_MESSAGES 1 /* Define if you have the __argz_count function. */ ! /* #undef HAVE___ARGZ_COUNT */ /* Define if you have the __argz_next function. */ ! /* #undef HAVE___ARGZ_NEXT */ /* Define if you have the __argz_stringify function. */ ! /* #undef HAVE___ARGZ_STRINGIFY */ /* Define if you have the dcgettext function. */ /* #undef HAVE_DCGETTEXT */ --- 51,72 ---- /* #undef HAVE_CATGETS */ /* Define as 1 if you have gettext and don't want to use GNU gettext. */ ! #define HAVE_GETTEXT 1 /* Define as 1 if you have the stpcpy function. */ ! #define HAVE_STPCPY 1 /* Define if your locale.h file contains LC_MESSAGES. */ #define HAVE_LC_MESSAGES 1 /* Define if you have the __argz_count function. */ ! #define HAVE___ARGZ_COUNT 1 /* Define if you have the __argz_next function. */ ! #define HAVE___ARGZ_NEXT 1 /* Define if you have the __argz_stringify function. */ ! #define HAVE___ARGZ_STRINGIFY 1 /* Define if you have the dcgettext function. */ /* #undef HAVE_DCGETTEXT */ *************** *** 84,96 **** #define HAVE_PUTENV 1 /* Define if you have the setenv function. */ ! /* #undef HAVE_SETENV */ /* Define if you have the setlocale function. */ #define HAVE_SETLOCALE 1 /* Define if you have the stpcpy function. */ ! /* #undef HAVE_STPCPY */ /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 --- 84,96 ---- #define HAVE_PUTENV 1 /* Define if you have the setenv function. */ ! #define HAVE_SETENV 1 /* Define if you have the setlocale function. */ #define HAVE_SETLOCALE 1 /* Define if you have the stpcpy function. */ ! #define HAVE_STPCPY 1 /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 *************** *** 99,105 **** #define HAVE_STRCHR 1 /* Define if you have the header file. */ ! /* #undef HAVE_ARGZ_H */ /* Define if you have the header file. */ #define HAVE_LIMITS_H 1 --- 99,105 ---- #define HAVE_STRCHR 1 /* Define if you have the header file. */ ! #define HAVE_ARGZ_H 1 /* Define if you have the header file. */ #define HAVE_LIMITS_H 1 *************** *** 111,117 **** #define HAVE_MALLOC_H 1 /* Define if you have the header file. */ ! /* #undef HAVE_NL_TYPES_H */ /* Define if you have the header file. */ #define HAVE_STRING_H 1 --- 111,117 ---- #define HAVE_MALLOC_H 1 /* Define if you have the header file. */ ! #define HAVE_NL_TYPES_H 1 /* Define if you have the header file. */ #define HAVE_STRING_H 1 diff -r -c gas-990104.orig/intl/config.status gas-990104/intl/config.status *** gas-990104.orig/intl/config.status Mon Jan 4 09:29:44 1999 --- gas-990104/intl/config.status Wed Jan 6 20:57:09 1999 *************** *** 2,10 **** # Generated automatically by configure. # Run this file to recreate the current configuration. # This directory was configured as follows, ! # on host andros.cygnus.com: # ! # ./configure --host=sun4 --target=sun4 --with-gnu-as --cache-file=../config.cache # # Compiler output produced by configure, useful for debugging # configure, is in ./config.log if it exists. --- 2,10 ---- # Generated automatically by configure. # Run this file to recreate the current configuration. # This directory was configured as follows, ! # on host merlin: # ! # ./configure --host=i686-pc-linux-gnu --target=is32 --exec-prefix=/usr/local/is32 --program-suffix=-is32 --with-gnu-as --with-gnu-ld --cache-file=../config.cache # # Compiler output produced by configure, useful for debugging # configure, is in ./config.log if it exists. *************** *** 14,21 **** do case "$ac_option" in -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r) ! echo "running ${CONFIG_SHELL-/bin/sh} ./configure --host=sun4 --target=sun4 --with-gnu-as --cache-file=../config.cache --no-create --no-recursion" ! exec ${CONFIG_SHELL-/bin/sh} ./configure --host=sun4 --target=sun4 --with-gnu-as --cache-file=../config.cache --no-create --no-recursion ;; -version | --version | --versio | --versi | --vers | --ver | --ve | --v) echo "./config.status generated by autoconf version 2.12.1" exit 0 ;; --- 14,21 ---- do case "$ac_option" in -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r) ! echo "running ${CONFIG_SHELL-/bin/sh} ./configure --host=i686-pc-linux-gnu --target=is32 --exec-prefix=/usr/local/is32 --program-suffix=-is32 --with-gnu-as --with-gnu-ld --cache-file=../config.cache --no-create --no-recursion" ! exec ${CONFIG_SHELL-/bin/sh} ./configure --host=i686-pc-linux-gnu --target=is32 --exec-prefix=/usr/local/is32 --program-suffix=-is32 --with-gnu-as --with-gnu-ld --cache-file=../config.cache --no-create --no-recursion ;; -version | --version | --versio | --versi | --vers | --ver | --ve | --v) echo "./config.status generated by autoconf version 2.12.1" exit 0 ;; *************** *** 26,32 **** done ac_given_srcdir=. ! ac_given_INSTALL="/usr/unsupported/bin/install -c" trap 'rm -fr Makefile config.h conftest*; exit 1' 1 2 15 --- 26,32 ---- done ac_given_srcdir=. ! ac_given_INSTALL="/usr/bin/ginstall -c" trap 'rm -fr Makefile config.h conftest*; exit 1' 1 2 15 *************** *** 42,48 **** s%@DEFS@%-DHAVE_CONFIG_H%g s%@LDFLAGS@%%g s%@LIBS@%%g ! s%@exec_prefix@%${prefix}%g s%@prefix@%/usr/local%g s%@program_transform_name@%s,x,x,%g s%@bindir@%${exec_prefix}/bin%g --- 42,48 ---- s%@DEFS@%-DHAVE_CONFIG_H%g s%@LDFLAGS@%%g s%@LIBS@%%g ! s%@exec_prefix@%/usr/local/is32%g s%@prefix@%/usr/local%g s%@program_transform_name@%s,x,x,%g s%@bindir@%${exec_prefix}/bin%g *************** *** 66,74 **** s%@CPP@%gcc -E%g s%@ALLOCA@%%g s%@USE_NLS@%yes%g ! s%@MSGFMT@%/usr/unsupported/bin/msgfmt%g ! s%@GMSGFMT@%/usr/unsupported/bin/msgfmt%g ! s%@XGETTEXT@%/usr/unsupported/bin/xgettext%g s%@USE_INCLUDED_LIBINTL@%yes%g s%@CATALOGS@%%g s%@CATOBJEXT@%.gmo%g --- 66,74 ---- s%@CPP@%gcc -E%g s%@ALLOCA@%%g s%@USE_NLS@%yes%g ! s%@MSGFMT@%no%g ! s%@GMSGFMT@%no%g ! s%@XGETTEXT@%:%g s%@USE_INCLUDED_LIBINTL@%yes%g s%@CATALOGS@%%g s%@CATOBJEXT@%.gmo%g *************** *** 214,219 **** --- 214,222 ---- cat $ac_file_inputs > conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out + rm -f conftest.in + mv conftest.out conftest.in + + cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out rm -f conftest.in mv conftest.out conftest.in cat > conftest.frag < conftest.out + rm -f conftest.in + mv conftest.out conftest.in + + cat > conftest.frag < conftest.frag < conftest.out diff -r -c gas-990104.orig/ld/Makefile.in gas-990104/ld/Makefile.in *** gas-990104.orig/ld/Makefile.in Mon Jan 4 09:24:33 1999 --- gas-990104/ld/Makefile.in Wed Jan 6 18:57:00 1999 *************** *** 248,253 **** --- 248,254 ---- ei386nbsd.o \ ei386nw.o \ ei386pe.o \ + eis32aout.o \ elnk960.o \ em68k4knbsd.o \ em68kaout.o \ *************** *** 1070,1075 **** --- 1071,1079 ---- ei386pe.c: $(srcdir)/emulparams/i386pe.sh \ $(srcdir)/emultempl/pe.em $(srcdir)/scripttempl/pe.sc ${GEN_DEPENDS} ${GENSCRIPTS} i386pe "$(tdir_i386pe)" + eis32aout.c: $(srcdir)/emulparams/is32aout.sh \ + $(srcdir)/emultempl/linux.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS} + ${GENSCRIPTS} is32aout "$(tdir_is32aout)" elnk960.c: $(srcdir)/emulparams/lnk960.sh \ $(srcdir)/emultempl/lnk960.em $(srcdir)/scripttempl/i960.sc ${GEN_DEPENDS} ${GENSCRIPTS} lnk960 "$(tdir_lnk960)" diff -r -c gas-990104.orig/ld/configure.tgt gas-990104/ld/configure.tgt *** gas-990104.orig/ld/configure.tgt Mon Jan 4 09:24:33 1999 --- gas-990104/ld/configure.tgt Wed Jan 6 18:59:31 1999 *************** *** 105,110 **** --- 105,111 ---- targ_extra_ofiles="deffilep.o pe-dll.o" ;; i[3456]86-*-mingw32*) targ_emul=i386pe ; targ_extra_ofiles="deffilep.o pe-dll.o" ;; + is32-*-*) targ_emul=is32aout ;; m8*-*-*) targ_emul=m88kbcs ;; a29k-*-udi) targ_emul=sa29200 ;; a29k-*-ebmon) targ_emul=ebmon29k ;; Only in gas-990104/ld/emulparams: is32aout.sh diff -r -c gas-990104.orig/opcodes/configure gas-990104/opcodes/configure *** gas-990104.orig/opcodes/configure Mon Jan 4 09:25:52 1999 --- gas-990104/opcodes/configure Wed Jan 6 19:02:43 1999 *************** *** 3809,3814 **** --- 3809,3815 ---- bfd_i386_arch) ta="$ta i386-dis.lo" ;; bfd_i860_arch) ;; bfd_i960_arch) ta="$ta $cgen_files i960-dis.lo i960c-opc.lo i960c-asm.lo i960c-dis.lo" ;; + bfd_is32_arch) ta="$ta is32-dis.lo" ;; bfd_m32r_arch) ta="$ta $cgen_files m32r-opc.lo m32r-asm.lo m32r-dis.lo" ;; bfd_m68k_arch) ta="$ta m68k-dis.lo m68k-opc.lo" ;; bfd_m88k_arch) ta="$ta m88k-dis.lo" ;; diff -r -c gas-990104.orig/opcodes/configure.in gas-990104/opcodes/configure.in *** gas-990104.orig/opcodes/configure.in Mon Jan 4 09:25:51 1999 --- gas-990104/opcodes/configure.in Wed Jan 6 19:03:27 1999 *************** *** 141,146 **** --- 141,147 ---- bfd_i386_arch) ta="$ta i386-dis.lo" ;; bfd_i860_arch) ;; bfd_i960_arch) ta="$ta $cgen_files i960-dis.lo i960c-opc.lo i960c-asm.lo i960c-dis.lo" ;; + bfd_is32_arch) ta="$ta is32-dis.lo" ;; bfd_m32r_arch) ta="$ta $cgen_files m32r-opc.lo m32r-asm.lo m32r-dis.lo" ;; bfd_m68k_arch) ta="$ta m68k-dis.lo m68k-opc.lo" ;; bfd_m88k_arch) ta="$ta m88k-dis.lo" ;; diff -r -c gas-990104.orig/opcodes/disassemble.c gas-990104/opcodes/disassemble.c *** gas-990104.orig/opcodes/disassemble.c Mon Jan 4 09:25:52 1999 --- gas-990104/opcodes/disassemble.c Wed Jan 6 19:04:09 1999 *************** *** 127,132 **** --- 127,137 ---- disassemble = print_insn_i960; break; #endif + #ifdef ARCH_is32 + case bfd_arch_is32: + disassemble = print_insn_is32; + break; + #endif #ifdef ARCH_m32r case bfd_arch_m32r: disassemble = print_insn_m32r; Only in gas-990104/opcodes: is32-dis.c Here follows the uuencode for binutils begin 644 gas.is32.extra.tar M8F9D+V)F9"UI;C,N:``````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````#$P,#8T-"``("`@,30T(``@("`Q-#0@`"`@("`@,S$Q-S(T M("`V-C0T-S0W,#7)I9VAT(#$Y.3`L(#DQ+"`Y,BP@.3,L(#DT+"`Y-2P@.38L M(#DW+"`Q.3DX"B`@($9R964@4V]F='=A2!#>6=N=7,@4W5P<&]R="X*"BHJ($Y/5$4Z(&)F M9"YH(&%N9"!B9F0M:6XR+F@@87)E($=%3D52051%1"!F:6QE2!O M9@I-15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)424-53$%2 M(%!54E!/4T4N("!3964@=&AE"D=.52!'96YE2`*"E1H92!B9F0N:"!F:6QE(&ES M(&=E;F5R871E9"!F2!B92!L;W-T+@H*06QL('1H92!P2P@86YD(&UA9VEC86QL>2!T:&ES(&9I;&4*=VEL;"!C:&%N M9V4@=&\@2!C;VUM86YD6]U7!E7!E9&5F(&5N=6T@8F9D7V)O;VQE86X@>V)F9%]F9F9A;'-E+"!B M9F1?='1T7-T96US('=I=&@@-C0M8FET(&9I;&4@;V9F2!T:&4@8F5S="!L;VYG+71E7!E(&!L;VYG)R!I7!E.PIT>7!E9&5F($)&1%](3U-47U5?-C1?0DE4('-Y;79A;'5E.PH* M(VEF;F1E9B!F<')I;G1F7W9M80HC:68@0D9$7TA/4U1?-C1"251?3$].1PHC M9&5F:6YE('-P"D@"(L M('@I"B-D969I;F4@9G!R:6YT9E]V;6$H9BQX*2!F<')I;G1F("AF+"`B)3`Q M-FQX(BP@>"D*(V5L"D@7`H@ M(&9P"DI"B-D969I;F4@"(L(%]B9F1?:6YT M-C1?:&EG:"`H>"DL(%]B9F1?:6YT-C1?;&]W("AX*2D*(V5N9&EF"B-E;F1I M9@H*(V5L7!E9&5F('5N7!E2!T:&%T('-I9VYE9"!A;F0@=6YS:6=N960@:6YT6UV86QU93L*='EP961E9B!U;G-I9VYE9"!L;VYG(&)F9%]S M:7IE7W1Y<&4["@HO*B!0"!O;B!S=')E86T@"(L('@I"B-D969I;F4@"(L('@I"@HC96YD:68@+RH@;F]T($)&1#8T("`J+PH*(V1E9FEN92!P M2!A<'!E87(@:6X@=&AE(&9L86=S(&9I96QD(&]F(&$@0D9$+B`@ M5&AE#`P"@HO*B!"1D0@8V]N=&%I M;G,@#`R"@HO*B!"1D0@:&%S(&QI;F4@;G5M M8F5R(&EN9F]R;6%T:6]N("AB87-I8V%L;'D@=7-E9"!F;W(@1E],3DY/(&EN M(&$*("`@0T]&1B!H96%D97(I+B`@*B\*(V1E9FEN92!(05-?3$E.14Y/("`) M,'@P-`H*+RH@0D9$(&AA#`X"@HO*B!"1D0@:&%S('-Y;6)O;',N M("`J+PHC9&5F:6YE($A!4U]364U3("`@(`DP>#$P"@HO*B!"1D0@:&%S(&QO M8V%L('-Y;6)O;',@*&)A2!U#0P"@HO*B!497AT('-E8W1I;VX@:7,@=W)I=&4@<')O M=&5C=&5D("AI9B!$7U!!1T5$(&ES(&YO="!S970L('1H:7,@:7,*("`@;&EK M92!A;B!A+F]U="!.34%'24,@9FEL92D@*'1H92!L:6YK97(@6YA M;6EC86QL>2!P86=E9"`H=&AI&%B;&4@*'1H:7,@ M;65A;G,@=&AA="!B9F1?&%M<&QE M+"!T:&ES(&ES('5S960@=&\@6UB;VQS(&YO="!B92!H87-H M960@=&\@96QI;6EN871E"B`@(&1U<&QI8V%T97,N("`J+PHC9&5F:6YE($)& M1%]44D%$251)3TY!3%]&3U)-050@,'@T,#`*"B\J(%1H:7,@9FQA9R!I;F1I M8V%T97,@=&AA="!T:&4@0D9$(&-O;G1E;G1S(&%R92!A8W1U86QL>2!C86-H M960@:6X*("`@;65M;W)Y+B`@268@=&AI6UB;VQS*2X@("HO"G1Y<&5D968@=6YS:6=N960@;&]N9R!S>6UI;F1E M>#L*"B\J($AO=R!T;R!P97)F;W)M(&$@7!E.PH*(V1E9FEN92!"1D1?3D]?34]215]364U"3TQ3("@H6UB;VP@ M6#L*("`@=&%R9V5T('-P96-I9FEC('!A"DM/G-E8W1I;VXI"B-D969I;F4@8F9D7V=E=%]O=71P=71?"QY*2`H*'@I+3YS96-T:6]N*2`]("AY*0HC M9&5F:6YE(&)F9%]A"D@*"AX*2T^"DM/FYA;64I"B\J4&5R:&%P6UB;VQ?8F9D*'@I("@H>"DM/G-E8W1I;VXM/F]W;F5R*2HO"B-D969I M;F4@8F9D7V%S>6UB;VQ?8F9D*'@I("@H>"DM/G1H95]B9F0I"B-D969I;F4@ M8F9D7V%S>6UB;VQ?9FQA=F]U6UB;VQ?8F9D*'@I+3YX M=F5C+3YF;&%V;W5R*0H*+RH@02!C86YO;FEC86P@87)C:&EV92!S>6UB;VPN M("`J+PHO*B!4:&ES(&ES(&$@='EP92!P=6X@=VET:"!S=')U8W0@6]U(&-A;&P@82!C87)S>6UO9V5N("HO"@H@(`HO*B!56T[("\J($9U;F-T M:6]N(&YA;64@*B\*("`@('5N7!E9&5F('-T6UB;VP*>R`*("!B M9F1?<')I;G1?6UB;VQ?86QL"GT@8F9D7W!R:6YT7W-Y;6)O;%]T M>7!E.PH@("`@"B\J($EN9F]R;6%T:6]N(&%B;W5T(&$@6UV86QU92!V86QU93L*("!C:&%R('1Y<&4["B`@0T].4U0@8VAA6UB;VP@;F%M92X@("HO"B`@=6YS:6=N M960@8VAA7!E(&-O9&4N("`J+PH*97AT97)N(&-O;G-T M(&-H87(@*F)F9%]G971?0I["B`@+RH@3F5X="!E;G1R>2!F;W(@=&AI2!I9B!T:&4@87)G=6UE;G0@:7,@3E5, M3"X@("HO"B`@6EN9R!A('-I>F4N("`J+PIE>'1EF4I*3L*"B\J($9R964@=7`@82!H87-H('1A M8FQE+B`@*B\*97AT97)N('9O:60@8F9D7VAA2!E>&ES="X@(%1H90H@("!#3U!9 M(&%R9W5M96YT(&UU'1E2DI.PH*+RH@4F5P;&%C92!A;B!E;G1R M>2!I;B!A(&AA'1E'1EF5?='EP92!B M9F1?F5?='EP92!S:7IE+"!B M9F1?7!E(&YI=&5M7!E(&)F9%]WF5?='EP92!S:7IE+"!B9F1?7!E(&YI=&5M'1E71E;W)D97(@/3T@ M0D9$7T5.1$E!3E]"247!E7!E6UB M;VQS*0HC9&5F:6YE(&)F9%]C;W5N=%]S96-T:6]N'9E8RT^'1E'1E'1E'1R*2`H2`J+`H)"0D)2`J+`H) M"0D@("`@("!B9F1?7!E*2DI.PIE>'1E7!E(&)F9%]E8V]F9E]D96)U9U]S:7IE"B`@4$%204U3("@H8F9D M("IA8F9D+"!S=')U8W0@96-O9F9?9&5B=6=?:6YF;R`J9&5B=6'1E'1E'1E'1EF5?9'EN86UI8U]S96-T:6]N'1E6YA M;6EC7W-E8W1I;VYS"B`@4$%204U3("@H8F9D("HL('-T6YA;6EC7W-E8W1I;VYS"B`@4$%2 M04U3("@H8F9D("HL('-T%]S:7IE7V1Y;F%M:6-?'1E%]S:7IE7V1Y;F%M:6-?7!E9&5F('-TPH@("\J(%=H870@=&AE('5S97(@87-K960@9F]R+B`@*B\*("!05%(@ M9&%T83L*("!B9F1?7!E('-I>F4["B`@+RH@5&AE(&%C='5A;"!W M:6YD;W<@=7-E9"!B>2!"1D0N("!3;6%L;"!U2!S:&%R92!A M('-I;F=L92!W:6YD;W<@:6YT;R!T:&4@;V)J96-T"B`@("`@9FEL92X@(%)E M860M=W)I=&4@=F5R2!T:&4*("`@("!A<'!L:6-A=&EO;CL@9&]N M)W0@=V%N="!T;R!G:79E('1H92!S86UE(')E9VEO;B!B86-K('=H96X@=&AE M"B`@("`@87!P;&EC871I;VX@=V%N=',@='=O('=R:71A8FQE(&-O<&EE'1EF5?='EP92P@8F9D7W=I;F1O=R`J+"!B;V]L96%N*2D["@HO*B!80T]& M1B!S=7!P;W)T(')O=71I;F5S(&9O6UB;VP*("!005)!35,@*"AB M9F0@*BP@6UB;VP*("!005)!35,@*"AB9F0@*BP@'1E&-O9F9?6YA;6EC7W-E8W1I;VYS M"B`@4$%204U3("@H8F9D("HL('-T&5N=#L*(V5N9&EF M"@IE>'1E'1E'1E(#!X.#`I("T@,'@X,"D*"B-D M969I;F4@8F9D7W!U=%\Q-BAA8F9D+"!V86PL('!T#,R+"`H<'1R*2D*(V1E9FEN92!B9F1?9V5T7W-I9VYE9%\S M,BAA8F9D+"!P='(I(%P*("`@("`@("`@("`@("`@($)&1%]314Y$*&%B9F0L M(&)F9%]G971X7W-I9VYE9%\S,BP@*'!T%]S:6=N961?-C0L("AP='(I*0H* M"B`O*B!">71E('-W87!P:6YG(&UA8W)O#,R M+"AP='(I*0HC9&5F:6YE(&)F9%]H7V=E=%]S:6=N961?,S(H86)F9"P@<'1R M*2!<"B`@("`@("`@("`@("`@("!"1D1?4T5.1"AA8F9D+"!B9F1?:%]G971X M7W-I9VYE9%\S,BP@*'!T#8T+"AV86PL('!T6YT:&5S:7IE M9"!F2X@*B\*(V1E9FEN92!3 M14-?0T]$12`@("`@("`P>#`R,`H*("`@("`@("`@+RH@5&AE('-E8W1I;VX@ M8V]N=&%I;G,@9&%T82!O;FQY+B`J+PHC9&5F:6YE(%-%0U]$051!("`@("`@ M(#!X,#0P"@H@("`@("`@("`O*B!4:&4@7!E(&ES('5S960@ M8GD@=&AE(&QI;FME6UB;VP*("`@("`@("`@("!W:&EC M:"!S:&]U;&0@8F4@=7-E9"!I;B!A(&-O;G-T#$Q,#`*(V1E9FEN92!314-?0T].4U1254-43U)?1$%402`P>#(Q,#`* M(V1E9FEN92!314-?0T].4U1254-43U)?0E-3("`P>#,Q,#`*"B`@("`@("`@ M("\J(%1H92!S96-T:6]N(&AA2!S96-T:6]N+B`@5&AI2!F;W(@=&AE(&QI;FMEF4N("!&25A-13H@ M06QT:&]U9V@@=&AI2!I#@P,`H*("`@("`@("`@+RH@ M5&AE('-E8W1I;VX@8V]N=&%I;G,@8V]M;6]N('-Y;6)O;',@*'-Y;6)O;',@ M;6%Y(&)E(&1E9FEN960*("`@("`@("`@("!M=6QT:7!L92!T:6UE#$P,#`P"@H@("`@("`@("`O*B!4:&4@8V]N M=&5N=',@;V8@=&AI2!P;VEN M=&5D('1O"B`@("`@("`@("`@8GD@=&AE(&-O;G1E;G1S(&9I96QD+B`@5&AI M&5C=71A8FQE(&%N9"!S:&%R960@;V)J96-T M#@P,#`P"@H@("`@("`@("\J(%=H96X@;&EN:VEN9RP@9'5P;&EC871E M('-E8W1I;VYS(&]F('1H92!S86UE(&YA;64@2!D;VYE M+B`@5&AI#$P,#`P,`H*("`@ M("`@("`O*B!)9B!314-?3$E.2U]/3D-%(&ES('-E="P@=&AI2!D=7!L:6-A=&4@ MF4N("`J+PHC9&5F:6YE(%-% M0U],24Y+7T154$Q)0T%415-?4T%-15]325I%(#!X-#`P,#`P"@H@("`@("`@ M("\J(%1H:7,@=F%L=64@9F]R(%-%0U],24Y+7T154$Q)0T%415,@;65A;G,@ M=&AA="!T:&4@;&EN:V5R"B`@("`@("`@("!S:&]U;&0@=V%R;B!I9B!A;GD@ M9'5P;&EC871E('-E8W1I;VYS(&-O;G1A:6X@9&EF9F5R96YT"B`@("`@("`@ M("!C;VYT96YT2!T:&4@;&EN:V5R(&%S('!A#$P,#`P,#`*"B`@("`@("`@+RH@($5N9"!O9B!S96-T M:6]N(&9L86=S+B`@*B\*"B`@("`@("`@+RH@4V]M92!I;G1E2!S;VUE M(&]F('1H92!L:6YK97(@8F%C:V5N9',N("`J+PH@("`@("`@=6YS:6=N960@ M:6YT(&QI;FME2!S;VUE(&QI;FME2!B9F0[(&EF(&ET)W,@;F]T('-E="P@=&AE M"B`@("`@("`@("`@8F%C:V5N9"!C86X@87-S:6=N(&%D9')E71EF5?='EP92!?8V]O:V5D M7W-I>F4["@H@("`@("`@("`O*B!4:&4@;W)I9VEN86P@71EF5? M='EP92!?F4["@H@("`@("`@("`O*B!)9B!T:&ES('-E8W1I;VX@ M:7,@9V]I;F<@=&\@8F4@;W5T<'5T+"!T:&5N('1H:7,@=F%L=64@:7,@=&AE M"B`@("`@("`@("`@;V9F71E(&EN"B`@("`@("`@("`@=&AE(&]U='!U="!S96-T:6]N+"!T M:&ES('9A;'5E('=O=6QD(&)E(#$P,"X@*B\*"B`@(&)F9%]V;6$@;W5T<'5T M7V]F9G-E=#L*"B`@("`@("`@("\J(%1H92!O=71P=70@,R`H;W(@."DN M("HO"@H@("!U;G-I9VYE9"!I;G0@86QI9VYM96YT7W!O=V5R.PH*("`@("`@ M("`@+RH@268@86X@:6YP=70@#L*"B`@(%!44B!U2`J'1E6UB;VP["F5X=&5R;B!C;VYS="!S=')U8W0@7=A M>2!005)!35,@*"AB9F0@*F%B9F0L($-/3E-4(&-H87(@*FYA;64I*3L*"F%S M96-T:6]N("H*8F9D7VUA:V5?F5?='EP92!V86PI*3L* M"F)O;VQE86X@"F)F9%]S971?PH@(&)F M9%]A'@@*B\*(V1E9FEN92!B9F1?;6%C:%]M-C@P,#`@,0HC9&5F:6YE M(&)F9%]M86-H7VTV.#`P."`R"B-D969I;F4@8F9D7VUA8VA?;38X,#$P(#,* M(V1E9FEN92!B9F1?;6%C:%]M-C@P,C`@-`HC9&5F:6YE(&)F9%]M86-H7VTV M.#`S,"`U"B-D969I;F4@8F9D7VUA8VA?;38X,#0P(#8*(V1E9FEN92!B9F1? M;6%C:%]M-C@P-C`@-PHC9&5F:6YE(&)F9%]M86-H7V-P=3,R("`X"B`@8F9D M7V%R8VA?=F%X+"`@("`@("`@+RH@1$5#(%9A>"`J+R`@(`H@(&)F9%]A&-E<'1I;VX@:7,@=&AE(")C82(L('=H:6-H(&ES M"B`@("`@("!I;F-O;7!A=&EB;&4@=VET:"!A;&P@;W1H97(@;6%C:&EN97,@ M97AC97!T(`H@("`@("`@(F-O"`@("`@("`@.`H*("!B9F1?87)C:%]A,CEK M+"`@("`@("`O*B!!340@,CDP,#`@*B\*("!B9F1?87)C:%]S<&%R8RP@("`@ M("`O*B!34$%20R`J+PHC9&5F:6YE(&)F9%]M86-H7W-P87)C("`@("`@("`@ M("`@("`@("`Q"B`O*B!4:&4@9&EF9F5R96YC92!B971W965N('8X<&QU'AX("HO M"B-D969I;F4@8F9D7VUA8VA?;6EP'@@*B\*("!B9F1?87)C:%]T M86AO92P@("`@("`O*B!#0TDO2&%R"`J+PH@(&)F9%]A2`J+PH@(&)F9%]A2`J+PH@(&)F9%]APH@(&EN M="!B:71S7W!E2!S<&5C:6%L(&9U;F-T:6]N M6UB;VP@=&\@2!W:&5N(&QI;FMI;F<@:3DV,"!C;V9F(&9I;&5S('=I M=&@@:3DV,"!B+F]U=`H@("`@("`@("`@7!E9&5F('-T0I[ M"B`@("`@("`@+RH@02!P;VEN=&5R(&EN=&\@=&AE(&-A;F]N:6-A;"!T86)L M92!O9B!P;VEN=&5R7!E(&9I96QD(&AA2!U'1E2X@5&AI7!E(&]F M(')E;&]C871I;VXL('5S92!B9F1?9V5T7W)E;&]C7W-I>F4N("`J+PH@(&EN M="!S:7IE.PH*("`@("`@("`O*B`@5&AE(&YU;6)E0H@("`@("`@("`@7!E("@J2`J'1E;F1E9"!R96QO8W,L('1H92!V86QU92!I;B!T:&4@;V9F M#`P,#`P,#`P+B`J+PH@(&)F9%]V M;6$@#`P,#`P,&9F+"!A;F0@R!<"B`@("`@(')E;&]C871I;VX@/2`P.R`@("`@("`@("`@("`@ M("`@("`@("`@("`@7`H@("`@?2`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@(%P*("`@(&5LR`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("!<"B`@("`@(')E;&]C871I;VX@/2!S>6UB M;VPM/G9A;'5E.R`@("`@("`@("`@("`@7`H@("`@?2`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@(%P*("!]("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!<"GT*=6YS:6=N960@ M:6YT(`IB9F1?9V5T7W)E;&]C7W-I>F4@(%!!4D%-4R`H*')E;&]C7VAO=W1O M7W1Y<&4@*BDI.PH*='EP961E9B!S=')U8W0@'0[ M"GT@87)E;&5N=%]C:&%I;CL*8F9D7W)E;&]C7W-T871U7!E"@IB9F1? M8VAE8VM?;W9EF4L"B`@("!U;G-I9VYE M9"!I;G0@7!E"@IB9F1?<&5R9F]R;5]R96QO8V%T:6]N M"B!005)!35,@*"AB9F0@*F%B9F0L"B`@("!A2P*("`@(%!44B!D871A+`H@("`@87-E8W1I;VX@*FEN<'5T7W-E8W1I;VXL M"B`@("!B9F0@*F]U='!U=%]B9F0L"B`@("!C:&%R("HJ97)R;W)?;65S7!E"@IB9F1?:6YS=&%L;%]R96QO M8V%T:6]N"B!005)!35,@*"AB9F0@*F%B9F0L"B`@("!A2P*("`@(%!44B!D871A+"!B9F1?=FUA(&1A=&%?PH@(%]D=6UM M>5]F:7)S=%]B9F1?71E(&1I2!R969E7!E7!E7!E6UB M;VP@;W(*(F%D9&5N9"(@:6X@2X*1F]R($=01$E3 M4%](23$V("@B9W!D:7-P(BD@6UB;VP@:7,@ M:6=N;W)E9"!W:&5N"G=R:71I;F<[('=H96X@6UB;VPN("!4:&4*861D96YD(&ES M('1H92!D:7-P;&%C96UE;G0@:6X@8GET97,@;V8@=&AE(")L9&$B(&EN6UB;VP@:7,@:&%N9&QE9"!A2!T:&4@&-E M<'0@=&AA="!T:&5R92!I6UB;VP@6UB;VPN("!4:&4@861D96YD(&ES(&EG;F]R960@=VAE;B!W6UB;VP@ M:7,@:6=N;W)E9"`H6UB M;VPI+"!A;F0@=&AE(")A9&1E;F0B(&EN9&EC871E2!D;V5S;B=T(&1O(&%N>2!O9B!T:&ES(&]P=&EM:7II;F7!E(&]F(')E;&]C('5S960@=&\@8G5I;&0@ M82!C;VYT2!A M(#,R(&)I="!W:61E(&%B2!D;V5S(&UA<"!T;R!O;F4@ M;V8@=&AE(&]T:&5R(')E;&]C871I;VX@='EP97,N("HO"B`@0D9$7U)%3$]# M7T-43U(L"@HO*B!!4DT@,C8@8FET('!C+7)E;&%T:79E(&)R86YC:"X@(%1H M92!L;W=EF5R;R!A;F0@:7,@;F]T('-T;W)E9"!I;B!T:&4@:6YS=')U8W1I;VXN("HO M"B`@0D9$7U)%3$]#7U1(54U"7U!#4D5,7T)204Y#2#DL"B`@0D9$7U)%3$]# M7U1(54U"7U!#4D5,7T)204Y#2#$R+`H@($)&1%]214Q/0U]42%5-0E]00U)% M3%]"4D%.0T@R,RP*"B\J($%R9V]N875T(%))4T,@0V]R92`H05)#*2!R96QO M8W,N"D%20R`R,B!B:70@<&,M2!D M871A(&%R96$@<&]I;G1E2!D871A(&%R96$@<&]I;G1E2!T=V\@8GET97,@:6X@ M=&AE"FEN71EF5R;RUS<&%C92!R96QO8V%T:6]N('5S960@=&\@ M9&5S8W)I8F4@=&\@=&AE"FQI;FME6UB;VP@6UB;VP@ M7!E9&5F M(&5N=6T@8F9D7W)E;&]C7V-O9&5?6UB;VPN(%1H:7,@:6YF;W)M871I;VX*("`@("`@("`@(&ES(&YE8V5S2!S;R!T:&%T(&$@8F%C:R!E;F0@8V%N('=O6UB;VPN"@H@("`@("`@("`@5&AI&-E<'0@=&AA="!S;VUE('-Y;6)O;',@ M<&]I;G0@=&\@=&AE(&=L;V)A;"!S96-T:6]N'0@;V8@ M=&AE('-Y;6)O;"X@5&AE(&YA;64@:7,@;&5F="!A;&]N92P@86YD(&YO="!C M;W!I960[('1H90H@("`@("`@("`@87!P;&EC871I;VX@;6%Y(&YO="!A;'1E M6UV86QU92!V86QU93L*"B`@("`@("`@+RH@071T#`R"@H@("`@("`@("\J(%1H92!S>6UB;VP@:&%S(&=L;V)A;"!S8V]P M92!A;F0@:7,@97AP;W)T960N(%1H92!V86QU92!I0H@ M("`@("`@("`@;65A;FEN9RX@*B\*(V1E9FEN92!"4T9?1$5"54='24Y'("`P M>#`X"@H@("`@("`@("\J(%1H92!S>6UB;VP@9&5N;W1E0H@("`@("`@("`@82!R96=U M;&%R(&=L;V)A;"!S>6UB;VP@;V8@=&AE('-A;64@;F%M92X@("HO"B-D969I M;F4@0E-&7U=%04L@("`@("`@(#!X.#`*"B`@("`@("`@+RH@5&AI6UB M;VP@=V%S(&-R96%T960@=&\@<&]I;G0@=&\@82!S96-T:6]N+"!E+F6UB;VQS+B`@*B\*(V1E9FEN M92!"4T9?4T5#5$E/3E]364T@,'@Q,#`*"B`@("`@("`@+RH@5&AE('-Y;6)O M;"!U#(P,`H*("`@("`@("`O*B!4:&4@9&5F875L="!V86QU92!F;W(@8V]M M;6]N(&1A=&$N("HO"B-D969I;F4@0D9$7T9/4E1?0T]-35]$149!54Q47U9! M3%5%(#`*"B`@("`@("`@+RH@26X@2!T:&4@=&%R9V5T($)&1"!P87)T('1O(&-O;G9E M>2!T:&ES(&EN9F]R;6%T:6]N+B`J+PH*(V1E9FEN92!"4T9?3D]47T%47T5. M1"`@("`P>#0P,`H*("`@("`@("`O*B!3:6=N86P@=&AA="!T:&4@6UB;VP@:7,@82!W87)N:6YG('-Y;6)O;"X@(%1H92!N M86UE(&ES(&$*("`@("`@("`@('=A'0*("`@("`@("`@('-Y;6)O;"P@82!W M87)N:6YG(&ES(&ES2!T:&4@;&EN:V5R+B`J+PHC9&5F:6YE($)3 M1E]705).24Y'("`@("`@(#!X,3`P,`H*("`@("`@("`O*B!3:6=N86P@=&AA M="!T:&4@6UB;VP@:7,@86X@ M:6YD:7)E8W0*("`@("`@("`@('!O:6YT97(@=&\@=&AE('-Y;6)O;"!W:71H M('1H92!S86UE(&YA;64@87,@=&AE(&YE>'0@6UB;VQS('1H870@8V]N=&%I;B!A(&9I;&4@;F%M92X@(%1H M:7,@:7,@=7-E9`H@("`@("`@("`@9F]R($5,1B!35%1?1DE,12!S>6UB;VQS M+B`@*B\*(V1E9FEN92!"4T9?1DE,12`@("`@("`@("`P>#0P,#`*"B`@("`@ M("`@+RH@4WEM8F]L(&ES(&9R;VT@9'EN86UI8R!L:6YK:6YG(&EN9F]R;6%T M:6]N+B`@*B\*(V1E9FEN92!"4T9?1%E.04U)0R`@("`@("`P>#@P,#`*"B`@ M("`@("`@+RH@5&AE('-Y;6)O;"!D96YO=&5S(&$@9&%T82!O8FIE8W0N("!5 M#$P,#`P"@H@ M(&9L86=W;W)D(&9L86=S.PH*("`@("`@("`O*B!!('!O:6YT97(@=&\@=&AE M('-E8W1I;VX@=&\@=VAI8V@@=&AI6UB;VP@:7,*("`@("`@("`@(')E M;&%T:79E+B`@5&AI6UB;VP["B-D969I;F4@8F9D7V=E=%]S>6UT86)? M=7!P97)?8F]U;F0H86)F9"D@7`H@("`@($)&1%]314Y$("AA8F9D+"!?8F9D M7V=E=%]S>6UT86)?=7!P97)?8F]U;F0L("AA8F9D*2D*8F]O;&5A;B`*8F9D M7VES7VQO8V%L7VQA8F5L(%!!4D%-4R`H*&)F9"`J86)F9"P@87-Y;6)O;"`J M6UT86(L7`H@("`@("`@("`@("`@("`@("`H86)F9"P@;&]C M871I;VXI*0IB;V]L96%N(`IB9F1?5]S>6UB;VPL("AA8F9D*2D*(V1E9FEN92!B9F1?;6%K M95]D96)U9U]S>6UB;VPH86)F9"QP='(L6UB;VP@*G-Y;6)O;"DI.PH*=F]I9"`*8F9D7W-Y;6)O;%]I;F9O(%!!4D%- M4R`H*&%S>6UB;VP@*G-Y;6)O;"P@6UB;VQ?9&%T82!005)!35,@*"AB M9F0@*FEB9F0L(&%S>6UB;VP@*FES>6TL(&)F9"`J;V)F9"P@87-Y;6)O;"`J M;W-Y;2DI.PH*(V1E9FEN92!B9F1?8V]P>5]P6UB;VPL(&]B9F0L(&]S>6UB;VPI(%P*("`@("!"1D1?4T5. M1"`H;V)F9"P@7V)F9%]C;W!Y7W!R:79A=&5?6UB;VPL(&]B9F0L(&]S>6UB;VPI*0IS M=')U8W0@7V)F9"`*>PH@("`@("\J(%1H92!F:6QE;F%M92!T:&4@87!P;&EC M871I;VX@;W!E;F5D('1H92!"1D0@=VET:"X@("HO"B`@("!#3TY35"!C:&%R M("IF:6QE;F%M93L@("`@("`@("`@("`@("`@"@H@("`@("\J($$@<&]I;G1E M'9E8SL*"B`@("`@+RH@5&\@ M879O:60@9')A9V=I;F<@=&]O(&UA;GD@:&5A9&5R(&9I;&5S(&EN=&\@979E M2!S=')U8W0N("`J+PH@("`@4%12(&EO M71H:6YG+B!)(&)E;&EE=F4@=&AA M="!T:&ES(&-A;B!B96-O;64@86QW87ES(&%N(&%D9"!O9@H@("`@("`@;W)I M9VEN+"!W:71H(&]R:6=I;B!S970@=&\@,"!F;W(@;F]N(&%R8VAI=F4@9FEL M97,N("`@*B\*"B`@("!F:6QE7W!T6UB;VP@=&%B;&4@9F]R M(&]U='!U="!"1D0@*'=I=&@@7-?9&%T82`J;V%S M>7-?;V)J7V1A=&$["B`@("`@('-T7-?87)?9&%T82`J;V%S M>7-?87)?9&%T83L*("`@("`@%]C;W)E7W-T%]C;W)E7V1A=&$["B`@("`@('-T2!T:&4@87!P;&EC871I;VX@=&\@:&]L9"!P5]R96-O9VYI>F5D+`H@(&)F9%]E7!E.PH*8F9D7V5R7!E(&5R7!E(&5RF5?F4@4$%204U3("@H8F9D("IA8F9D*2D["@IV M;VED(`IB9F1?F4@4$%204U3("@H8F9D("IA8F9D+"!I;G0@ M:2DI.PH*8F9D7W9M82`*8F9D7W-C86Y?=FUA(%!!4D%-4R`H*$-/3E-4(&-H M87(@*G-T5]PF5O9E]H96%D97)S+"`H86)F M9"P@6US+"!O9F8L(&9I;&4L(&9U;F,L(&QI;F4I(%P*("`@("!" M1D1?4T5.1"`H86)F9"P@7V)F9%]F:6YD7VYE87)E71H:6YG('5S969U;"!A="!A;&PL M(&9O%]S96-T:6]N*&%B9F0L('-E M8W1I;VXL(&QI;FM?:6YF;RP@86=A:6XI(%P*("`@("`@($)&1%]314Y$("AA M8F9D+"!?8F9D7W)E;&%X7W-E8W1I;VXL("AA8F9D+"!S96-T:6]N+"!L:6YK M7VEN9F\L(&%G86EN*2D*"B-D969I;F4@8F9D7V=C7W-E8W1I;VYS*&%B9F0L M(&QI;FM?:6YF;RD@7`H@("`@("`@0D9$7U-%3D0@*&%B9F0L(%]B9F1?9V-? M6UB;VQS*&%B9F0L(&EN9F\I(%P*("`@ M("`@($)&1%]314Y$("AA8F9D+"!?8F9D7VQI;FM?861D7W-Y;6)O;',L("AA M8F9D+"!I;F9O*2D*"B-D969I;F4@8F9D7V9I;F%L7VQI;FLH86)F9"P@:6YF M;RD@7`H@("`@("`@0D9$7U-%3D0@*&%B9F0L(%]B9F1?9FEN86Q?;&EN:RP@ M*&%B9F0L(&EN9F\I*0H*(V1E9FEN92!B9F1?9G)E95]C86-H961?:6YF;RAA M8F9D*2!<"B`@("`@("!"1D1?4T5.1"`H86)F9"P@7V)F9%]F6UT M86)?=7!P97)?8F]U;F0H86)F9"D@7`H@("`@("`@0D9$7U-%3D0@*&%B9F0L M(%]B9F1?9V5T7V1Y;F%M:6-?6UB;VQS*2!<"B`@("`@ M("!"1D1?4T5.1"`H86)F9"P@7V)F9%]C86YO;FEC86QI>F5?9'EN86UI8U]S M>6UT86(L("AA8F9D+"!A6US*2!<"B`@("`@("!"1D1?4T5.1"`H86)F M9"P@7V)F9%]C86YO;FEC86QI>F5?9'EN86UI8U]R96QO8RP@*&%B9F0L(&%R M96QS+"!A'1E6UB;VP@*BHI*3L*"G-Y;6EN9&5X(`IB9F1?9V5T M7VYE>'1?;6%P96YT(%!!4D%-4R`H*&)F9"`J86)F9"P@&5C=71A8FQE7W`*(%!!4D%-4R`H*&)F9"`J8V]R95]B9F0L(&)F M9"`J97AE8U]B9F0I*3L*"B-D969I;F4@0D9$7U-%3D0H8F9D+"!M97-S86=E M+"!A'9E8RT^ M;65S'9E8R`F)B`H8F9D*2T^ M>'9E8RT^;65S'9E8R`F)B`H8F9D*2T^>'9E8RT^;65S M7-?9FQA=F]U%]F;&%V;W5R+`H@(&)F9%]T87)G971?%]F;&%V;W5R+`H@(&)F9%]T M87)G971?PH@(&-H87(@*FYA;64["B`@96YU M;2!B9F1?9FQA=F]U71E M;W)D97(["B`@96YU;2!B9F1?96YD:6%N(&AE861E71E;W)D97(["B`@ M9FQA9W=O%]N86UE;&5N.PH@(&)F9%]V;6$@("`@("`H*F)F9%]G971X-C0I(%!! M4D%-4R`H*&-O;G-T(&)F9%]B>71E("HI*3L*("!B9F1?71E("HI*3L*("!B9F1?=FUA("`@("`@*"IB9F1?9V5T M>#,R*2!005)!35,@*"AC;VYS="!B9F1?8GET92`J*2D["B`@8F9D7W-I9VYE M9%]V;6$@*"IB9F1?9V5T>%]S:6=N961?,S(I(%!!4D%-4R`H*&-O;G-T(&)F M9%]B>71E("HI*3L*("!V;VED("`@("`@("`@*"IB9F1?<'5T>#,R*2!005)! M35,@*"AB9F1?=FUA+"!B9F1?8GET92`J*2D["B`@8F9D7W9M82`@("`@("@J M8F9D7V=E='@Q-BD@4$%204U3("@H8V]N%]S:6=N961?-C0I M(%!!4D%-4R`H*&-O;G-T(&)F9%]B>71E("HI*3L*("!V;VED("`@("`@("`@ M*"IB9F1?:%]P=71X-C0I(%!!4D%-4R`H*&)F9%]V;6$L(&)F9%]B>71E("HI M*3L*("!B9F1?=FUA("`@("`@*"IB9F1?:%]G971X,S(I(%!!4D%-4R`H*&-O M;G-T(&)F9%]B>71E("HI*3L*("!B9F1?#,R*2!005)!35,@*"AB9F1?=FUA M+"!B9F1?8GET92`J*2D["B`@8F9D7W9M82`@("`@("@J8F9D7VA?9V5T>#$V M*2!005)!35,@*"AC;VYS="!B9F1?8GET92`J*2D["B`@8F9D7W-I9VYE9%]V M;6$@*"IB9F1?:%]G971X7W-I9VYE9%\Q-BD@4$%204U3("@H8V]N7!E7V5N9%TI M(%!!4D%-4R`H*&)F9"`J*2D["B`@8F]O;&5A;B`@("`@("`@("`@("`H*E]B M9F1?7!E7V5N9%TI(%!!4D%-4R`H*&)F9"`J*2D["@H@("`O*B!'96YE M2!N96-E5]P5]P6UB;VQ? M9&%T82D@4$%204U3("@H8F9D("HL(&%S>6UB;VP@*BP*("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M(&)F9"`J+"!A2!P;VEN=',N("`J+PHC9&5F:6YE($)&1%]*54U07U1!0DQ%7T-/4D4H3D%- M12E<"D-!5"A.04U%+%]C;W)E7V9I;&5?9F%I;&EN9U]C;VUM86YD*2Q<"D-! M5"A.04U%+%]C;W)E7V9I;&5?9F%I;&EN9U]S:6=N86PI+%P*0T%4*$Y!344L M7V-O&5C=71A8FQE7W`I(%!!4D%-4R`H*&)F9"`J+"!B9F0@*BDI.PH*("`@ M+RH@07)C:&EV92!E;G1R>2!P;VEN=',N("`J+PHC9&5F:6YE($)&1%]*54U0 M7U1!0DQ%7T%20TA)5D4H3D%-12E<"D-!5"A.04U%+%]S;'5R<%]A'1E;F1E9%]N M86UE7W1A8FQE*0H@("`@("`@("`@("`@4$%204U3("@H8F9D("HL(&-H87(@ M*BHL(&)F9%]S:7IE7W1Y<&4@*BP@8V]N'1?87)C:&EV961?9FEL92D@4$%204U3 M("@H8F9D("IA"AB+&DI($)&1%]314Y$*&(L(%]B9F1?9V5T7V5L=%]A=%]I M;F1E>"P@*&(L:2DI"B`@8F9D("H@("`@*"I?8F9D7V=E=%]E;'1?871?:6YD M97@I(%!!4D%-4R`H*&)F9"`J+"!S>6UI;F1E>"DI.PH@(&EN="`@("`@("@J M7V)F9%]S=&%T7V%R8VA?96QT*2!005)!35,@*"AB9F0@*BP@6UB;VQS*2Q< M"D-!5"A.04U%+%]M:6YI5]S>6UB;VPI(%!!4D%-4R`H*&)F9"`J*2D["B`@=F]I M9"`@("`@("`@("`H*E]B9F1?<')I;G1?2`J*2D["B`@8F]O;&5A M;B`@("`H*E]B9F1?9FEN9%]N96%R97-T7VQI;F4I(%!!4D%-4R`H*&)F9"`J M86)F9"P*("`@("`@("`@("`@("`@("`@("!S=')U8W0@6UB M;VQS"B`@("!W:&EL92!U2!U6UB;VPI(%!!4D%-4R`H*`H@("`@("`@8F9D("IA8F9D+`H@ M("`@("`@=F]I9"`J<'1R+`H@("`@("`@=6YS:6=N960@;&]N9R!S:7IE*2D[ M"B-D969I;F4@8F9D7W)E861?;6EN:7-Y;6)O;',H8BP@9"P@;2P@6UB M;VP@*B@J7VUI;FES>6UB;VQ?=&]?7!E M7VQO;VMU<"D@4$%204U3("@H8F9D("IA8F9D+`H@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@8F9D7W)E;&]C7V-O9&5?7!E M(&-O9&4I*3L*"B`@("\J(%)O=71I;F5S('5S960@=VAE;B!W7!E*2D["@H@("`O*B!2;W5T:6YE71E M("ID871A+"!B;V]L96%N(')E;&]C871E86)L92P*("`@("`@("`@("`@("`@ M("`@("!S=')U8W0@F5?9'EN M86UI8U]S>6UT86(I+%P*0T%4*$Y!344L7V=E=%]D>6YA;6EC7W)E;&]C7W5P M<&5R7V)O=6YD*2Q<"D-!5"A.04U%+%]C86YO;FEC86QI>F5?9'EN86UI8U]R M96QO8RD*("`@+RH@1V5T('1H92!A;6]U;G0@;V8@;65M;W)Y(')E<75I6YA;6EC('-Y;6)O;',N("`J M+PH@(&QO;F<@("@J7V)F9%]C86YO;FEC86QI>F5?9'EN86UI8U]S>6UT86(I M"B`@("!005)!35,@*"AB9F0@*BP@2`J*BDI.PH@("`O*B!'970@=&AE(&%M;W5N="!O9B!M96UOF5?9'EN86UI8U]R96QO8RD* M("`@(%!!4D%-4R`H*&)F9"`J+"!A2!O9@I-15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!0 M05)424-53$%2(%!54E!/4T4N("!3964@=&AE"D=.52!'96YE7-D97`N:"(*(VEN8VQU9&4@(FQI8F)F M9"YH(@H*"F-O;G-T(&)F9%]A"D@,0HC9&5F:6YE($)95$537TE.7U=/4D0@-`HC9&5F:6YE($5. M5%)97T-!3E]"15]:15)/"B-D969I;F4@3E]32$%2141?3$E"*'@I(#`*(V1E M9FEN92!415A47U-405)47T%$1%(@,`HC9&5F:6YE(%1!4D=%5%]004=%7U-) M6D4@-#`Y-@HC9&5F:6YE(%-%1TU%3E1?4TE:12!405)'151?4$%'15]325I% M"B-D969I;F4@1$5&055,5%]!4D-((&)F9%]A7-D97`N:"(*(VEN8VQU9&4@(FQI8F)F9"YH(@HC:6YC;'5D92`B86]U M="]A;W5T-C0N:"(*(VEN8VQU9&4@(F%O=70O7,@9V5N97)A=&4@44U!1TE#(&9I;&5S(&EN('!R969EPH@(&]B:E]A;W5T M7W-U8F9O7!E(&-O2X@("HO"@IS=&%T:6,@8F]O;&5A;@IIPH@('-T'1E&5C(&5X96-?8GET97,["B`@&5C<"D["@H@(')E='5R;B!T2!O9@H@("!-15)# M2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)424-53$%2(%!54E!/ M4T4N("!3964@=&AE"B`@($=.52!'96YER)I;2(L(#-]+`H@('LB96TB+"`T?2P*("![(G-T(BP@-7TL"B`@ M>R)R82(L(#9]+`H@('LBR)R9"(L M(#E]+`H*("![3E5,3"P@+3%]+`I].PHC9&5F:6YE($Y/7U)%1TE35$52("`@ M,`HC9&5F:6YE(%)%1U].04U%7U-)6D4@,@H*='EP961E9B!E;G5M('L@:6YT M97)N86PL(&1I&-E<'0@:6YS:61E"B`@(&%N;W1H M97(@8V]M;65N="`J+PIC;VYS="!C:&%R(&-O;6UE;G1?8VAA'`@:6X@9FQO871I;F<@<&]I;G0@;G5M M'`@8VAA7!E4R!M M9%]PR)S M=')I;F6UB;VP]*'-Y;6)O;%,@*BE.54Q,.PDO*B!0 MF4L('-I>F5S("ID97-T4VEZ92P@8VAA"DI.PIS=&%T:6,@:6YT("`@ M9V5T4F5G("`@("`@(%!!4D%-4R`H*&-H87(@*G!;72DI.PIS=&%T:6,@8VAA MPH@ M("`@("!I;G!U=%]L:6YE7W!O:6YT97(@*ST@-3L*("`@("`@PH@('M.54Q,+"!N;U]AF4@/2!S M:7IE;V8H;61?;&]N9V]P=',I.PH*:6YT"FUD7W!APH@(')E='5R;B`P M.PI]"@IV;VED"FUD7W-H;W=?=7-A9V4@*'-T5]F:7@@*&9I>%`L('9A;'5E*0H@("`@(&9I>%,@*F9I M>%`["B`@("`@=F%L=654("IV86QU93L*>PH@(&-H87(@*F)U9B`](&9I>%`M M/F9X7W=H97)E("L@9FEX4"T^9GA?9G)A9RT^9G)?;&ET97)A;#L*("!O9F9S M9714('9A;#L*"B`@=F%L(#T@*G9A;'5E.PH@(&%S7!E(#P@0D9$7U)%3$]#7U5.55-%1"D["B`@9FEX4"T^9GA?861D;G5M M8F5R(#T@=F%L.PDO*B!296UE;6)E%`M/F9X7W)?='EP92D*("`@('L*("`@(&-A7!E.B`P>"4P,G@B+"!F M:7A0+3YF>%]R7W1Y<&4I.PH@("`@("!B%QN(BP@:6YS;BT^;W!C;V1E*3L*("!F<')I;G1F("AS=&1E6UB;VP@/2`E'`N6%]A9&1?'`N6%]O<%]S>6UB;VP@ M(3T@3E5,3"D*"2`@("`_("A37T=%5%].04U%("AI;G-N+3YE>'`N6%]O<%]S M>6UB;VPI"@D@("`@("`@/R!37T=%5%].04U%("AI;G-N+3YE>'`N6%]O<%]S M>6UB;VPI"@D@("`@("`@.B`B/S\_(BD*"2`@("`Z("(P(BDI.PH@(&9P2!B965N(&AA;F1L960*("`@8GD@=&AE(&=E;F5R:6,@9G)O M;G0@96YD+B`@5V4@:G5S="!P87)S92!O<&-O9&4@86YD(&]P97)A;F1S+"!A M;F0*("`@<')O9'5C92!T:&4@8GET97,@;V8@9&%T82!A;F0@71E(&]P8V]D92`M(&YO('!APH@("`@ M("!D96UA;F1?96UP='E?F4@=&\@ M=&AE(&%P<')O<')I871E(&)O=6YD87)Y+B`@*B\*=F%L=654"FUD7W-E8W1I M;VY?86QI9VX@*'-E9VUE;G0L('-I>F4I"B`@("`@F4["0D)+RH@0GET92!A M;&EG;FUE;G0@:7,@9FEN92`J+PI]"@H*+RH@17AA8W1L>2!W:&%T('!O:6YT M(&ES(&$@4$,M%,@*F9I>%`["GL*("!A%]F'`M/F9X7W-I M>F4L(&9I>'`M/F9X7W!C'`M/F9X7W!C&UA;&QO8R`H6U?<'1R7W!T M%]A9&1S>2T^8G-Y;3L*("!R96PM/F%D9')E%]F'`M/F9X7W!C%]A9&1N=6UB97(["B`@96QS90H@("`@7!E7VQO;VMU<"`H'`I"B`@("`@87-E8W1I;VX@*G-E8W1I;VX["B`@("`@9FEX4R`J M9FEX<#L*>PH@(&%R96QE;G0@*G)E;&]C.PH@(&)F9%]R96QO8U]C;V1E7W)E M86Q?='EP92!C;V1E.PH*(V1E9FEN92!&*%-:+%!#4D5,*0D)*"@H4UHI(#P\ M(#$I("L@*%!#4D5,*2D*("!S=VET8V@@*$8@*&9I>'`M/F9X7W-I>F4L(&9I M>'`M/F9X7W!C5]S:7IE7W0@*'-T9&]U='!U="P@ M%]F'`M/F9X7W!C'`M/F9X7V%D9&YU;6)E6UB;VQ3("H*;61?=6YD969I;F5D7W-Y;6)O;"`H;F%M92D*("`@("!C:&%R M("IN86UE.PI["B`@PH)("!I9BAS>6UB;VQ?9FEN9"AN86UE*2D@"@D@ M("`@87-?8F%D*")'3U0@86QR96%D>2!I;B!S>6UB;VP@=&%B;&4B*3L*"2`@ M1T]47W-Y;6)O;"`]('-Y;6)O;%]N97<@*&YA;64L('5N9&5F:6YE9%]S96-T M:6]N+"`*"0D)"2`@("AV86QU950I(#`L("9Z97)O7V%D9')EF5S*'-I>F53 M='(L("9T:&5?:6YS;BYS;W5R8V53:7IE+"`F=&AE7VENF4L M(")L;V%D(BD["B`@<&%RF53='(I"F-H87(@*F]P M97)A;F13=&%R=#L*8VAAPH@(&-O;&QE8W13:7IE"D*8VAA'!R97-S:6]N M4R!T:&5?;W!E'!R97-S:6]N4R`J;W!EPH@("`@+RH@ M9F]U;F0@:6UM961I871E(&UO9&4@*B\*("`@('1H95]I;G-N+FUO9&4@/2!I M;6UE9&EA=&4["B`@("!I9B`H:6YS;DEN9&5X(#T]($Q/041?24Y$15@I('L* M("`@("`@;W!EPH@("`@ M("!A'!E8W1I;F<@*2!A M="!T:&4@96YD(&]F(&EN9&ER96-T(&UO9&4@;W!E&5D.PH@("`@("!T:&5?:6YS;BYR96<@(#T@9V5T4F5G*"9O<&5R86YD4W1A MPH)87-? M8F%D*")E>'!E8W1I;F<@*2!A="!T:&4@96YD(&]F(&EN9&5X960@;6]D92!O M<&5R86YD(BD["B`@("`@('T*("`@('T@96QS92!["B`@("`@('1H95]I;G-N M+FUO9&4@/2!D:7)E8W0["B`@("!]"B`@?0I]"@H*PH@('=H:6QE("AIPH@("`@PH@(&-H87(@*G-A=F4@/2!I;G!U=%]L M:6YE7W!O:6YT97(["B`@8VAA'`@/2`J;W!E M"D*:6YT(&EN#L*>PH@ M('-W:71C:"`H=&AE7VENPH*("!C87-E(&EN=&5R;F%L.@H@ M("`@96YC;V1E26YS;BAIF4L('1H95]I;G-N+F1E71E M+"!T:&5?:6YS;BYR96'`N6%]A9&1?;G5M M8F5R(#P@,'@X,"D@)B8@*'1H95]I;G-N+F5X<"Y87V%D9%]N=6UB97(@/CT@ M+3!X.#`I*2!["@EE;F-O9&5);G-N*&ES,S)?;W!C;V1EF4L(&)Y=&4L('1H95]I;G-N+G)E9RP@=&AE7VEN71E*3L*("`@ M("`@?2!E;'-E(&EF("@H=&AE7VEN%TN;W!C M;V1E+"!T:&5?:6YS;BYS;W5R8V53:7IE+"!T:&5?:6YS;BYD97-T4VEZ92P@ M=V]R9"P@=&AE7VENPH)96YC;V1E26YS;BAIF4L('1H95]I;G-N+F1EF4L(&1W;W)D+"!T:&5?:6YS;BYR96'`H-"D["B`@("!]"B`@("!B'`@ M*&9R86=?;F]W+`H)"2`H:6YT*2`H=&]0("T@9G)A9U]N;W'!R97-S:6]N4R`J M*2`F=&AE7VEN%]N97=?97AP("AFF4@*B\*"0D@*&5X<')E'`L M"@D)($9!3%-%+`H)"2!"1D1?4D5,3T-?."D["B`@9&5F875L=#H*("`@(&%S M7V9A=&%L*")I;F-OF5S('-I>F4["GL*("!C:&%R M("IT:&ES9G)A9SL*"B`@71E.@H@ M("`@=&AIF4@=F%L=64B*3L*("!]"GT*"@IS=&%T:6,@=F]I9`IE;F-O M9&5);G-N("AO<&-O9&4L('-O=7)C95-I>F4L(&1EF5S('-O=7)C95-I>F4["G-I M>F5S(&1EF4@/#P@-"D@?"!R96'0@8GET92`J+PH@(&UD7VYU;6)EF53 M='(L('-O=7)C95-I>F4L(&1EF53='(["G-I>F5S("IS;W5R8V53:7IE.PIS:7IEF4["F-H M87(@*F5RPH@(&EF("AS=')N8VUP*'-I>F53='(L("(N8B(L M(#(I(#T](#`I('L*("`@("IS;W5R8V53:7IE(#T@8GET93L*("!](&5LPH@("`@*G-O M=7)C95-I>F4@/2!W;W)D.PH@('T@96QS92!I9B`HF4@;VX@ M)R5S)R(L(&5RF53='(@ M*ST@,CL*("!I9B`HF4@/2!B>71E.PH@('T@96QS92!I9B`HF4@/2!W;W)D M.PH@('T@96QS92!I9B`HF4@/2!D=V]R9#L*("!](&5LPH@("`@87-? M8F%D*")I;G9A;&ED(&1EF4@;VX@)R5S)R(L(&5R71EPH@(&%S7V9A=&%L("@B;61? M;G5M8F5R7W1O7V9I96QD(&YO="!D969I;F5D(BD["B`@;61?;G5M8F5R7W1O M7V-H87)S("AB=68L('9A;"P@;F)Y=&5S*3L*?0H*+RH@5'5R;B!A('-T71E7!E+"!L:710+"!S:7IE4"D*("`@("!C:&%R('1Y M<&4["B`@("`@8VAAF50.PI["B`@87-? M9F%T86P@*")M9%]A=&]F(&YO="!N965D960@:6X@=&AE(&ES,S(B*3L*("!R M971U2!N965D('1O(&5N8V]D92!M9%]C6UB;VPI"B`@("`@8VAA6UB;VQ3("IT;U]S>6UB;VP["GL*("!A&,P M.PH@('!T#`P.PH@(&9I>%]N97<@*&9R86F5?8F5F;W)E7W)E;&%X("AF7!E M*0H@("`@(&9R86=3("IFPH@(&%S7V9A=&%L("@B4F5L87AA=&EO;B!S:&]U;&0@;F5V97(@;V-C=7(B M*3L*("!R971U2!A(&UO6=N=7,@4W5P M<&]R="P@,3,@2G5L>2`Q.3DS+B`@*B\*"B\J($=I=F5N(&$@9FEX4R!S=')U M8W1U%]N977!E('1O('5S92!F;W(@ M:70N("`J+PH*'`I"B`@("`@ M9FEX4R`J9FEX<#L*>PH@('-W:71C:"`H9FEX<"T^9GA?7!E*0H@("`@ M>PH@("`@8V%S92!214Q/0U],3S$V.@H@("`@("!R971U2!I;B!T:&4@;V)J96-T"B`@(&9I;&4@:71S96QF M+B`@*B\*"G9O:60*;61?87!P;'E?9FEX("AF:7AP+"!V86PI"B`@("`@9FEX M4R`J9FEX<#L*("`@("!L;VYG('9A;#L*>PH@(&-H87(@*F)U9CL*"B`@8G5F M(#T@9FEX<"T^9GA?9G)A9RT^9G)?;&ET97)A;"`K(&9I>'`M/F9X7W=H97)E M.PH@(&9I>'`M/F9X7V]F9G-E="`](#`["@H@('-W:71C:"`H9FEX<"T^9GA? M7!E*0H@("`@>PH@("`@8V%S92!214Q/0U])5S$V.@H@("`@("!F:7AP M+3YF>%]O9F9S970@/2!V86P@/CX@,38["B`@("`@(&)U9ELR72`]('9A;"`^ M/B`X.PH@("`@("!B=69;,UT@/2!V86P["B`@("`@(&)R96%K.PH*("`@(&-A M'`M/F9X7V]F9G-E="`]('9A;"`^/B`Q-CL*("`@("`@8G5F6S!=(#T@ M=F%L(#X^(#@["B`@("`@(&)U9ELQ72`]('9A;#L*("`@("`@8G)E86L["@H@ M("`@8V%S92!214Q/0U]00S$V.@H@("`@("!B=69;,%T@/2!V86P@/CX@,3`[ M"B`@("`@(&)U9ELQ72`]('9A;"`^/B`R.PH@("`@("!B%,@*F9I>'`["GL*("!S=VET8V@@*&9I>'`M M/F9X7W)?='EP92D*("`@('L*("`@(&-A'`M/F9X7V9R86%]W M:&5R92`M(#(["B`@("!C87-E(%)%3$]#7U!#,C8Z"B`@("`@(')E='5R;B!F M:7AP+3YF>%]F"(*```````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````&EN8VQU9&4O;W!C;V1E+VES,S(N:``````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````Q,#`V-#0@`"`@(#$T-"``("`@ M,30T(``@("`@("`@-C`V,2`@-C8T-#7)I9VAT("A#*2`Q M.3@Y+"`Q.3DR($9R964@4V]F='=A6]U(&-A;B!R961I0H@("!I="!U;F1E0H@("!T M:&4@1G)E92!3;V9T=V%R92!&;W5N9&%T:6]N.R!E:71H97(@=F5R6]U2!L871EPH@("\J"2`@($]P8V]D90D@("!-;F5M;VYI8R`J+PH* M("`@("`@("`@("`Q,C@L("`@("`@("`@("`@(FQO860B+`H@("`@("`@("`@ M(#$Y,BP@("`@("`@("`@("`B2(L"B`@ M("`@("`@("`@,SF5O9B!I"(*5$%21T54 M7U!!1T5?4TE:13TP>#(P"E1%6%1?4U1!4E1?041$4CTP>#$P,#`*3D].4$%' M141?5$585%]35$%25%]!1$12/3!X,3`P,`I!4D-(/6ES,S(*```````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````;W!C;V1E6]U(&-A;B!R961I0II="!U M;F1E0IT:&4@1G)E92!3;V9T=V%R92!&;W5N9&%T M:6]N.R!E:71H97(@=F5R6]U2!L871EF5S(',I*3L*2`@4$%204U3*"AD M:7-A&EM=6T@;&5N9W1H M(&]F(&%N(&EN&-L=7-I=F4I M(&%R92!V86QI9"X@(%)E='5R;G,@,2!F;W(@71E("IA9&1R.PI["B`@:68@*&%D9'(@/B`H*'-TPH@("`@:6YT('-T871U%]F971C:&5D(#T@861DF4@*&EN9F\L(',I"B`@ M("`@9&ES87-S96UB;&5?:6YF;R`J:6YF;SL*("`@("!S:7IE71E(#H@("@J:6YF;RT^9G!R:6YT9E]F=6YC*2`HR)I;2(L(#-]+`H@('LB96TB+"`T?2P*("![(G-T(BP@-7TL M"B`@>R)R82(L(#9]+`H@('LBR)R M9"(L(#E]+`H*("![3E5,3"P@+3%]+`I].PH*"G-T871I8R!V;VED"G!R:6YT M4F5G("`H:6YF;RP@2AI;F9O+"!I;G13:7IE+"!B M=69F97(I"B`@("`@9&ES87-S96UB;&5?:6YF;R`J:6YF;SL*("`@("!S:7IE M71E("IB=69F97(["GL*("!&24Q%("IS M=')E86T@/2!I;F9O+3YS=')E86T["B`@:6YT("!V86P@("`@(#T@,#L*"B`@ MF4R:6YT("AS*0H@("`@('-I>F5S(',["GL*("!S=VET8V@@ M*',I('L*"B`@8V%S92!B>71E(#H@PH@($9)3$4@*G-TF5S(&EN=%-I>F4L M('-I>F4Q+"!S:7IE,CL*("!I;G0@(')E9SL*("!M;V1E%]F M971C:&5D(#T@<')I=BYT:&5?8G5F9F5R.PH@('!R:78N:6YS;E]S=&%R="`] M(&UE;6%D9'(["B`@:68@*'-E=&IM<"`H<')I=BYB86EL;W5T*2`A/2`P*0H@ M("`@+RH@17)R;W(@71E(&]P8V]D92`J+PH@("`@:68@ M*&)U9F9EPH@("`@("`H*FEN9F\M/F9PPH@("`@("`H*FEN9F\M/F9P%TB+"`H:6YT*6)U9F9EPH@("`@:68@*&)U9F9EF4Q(#T@*&)U9F9EF4Q*3L*("`@('!R:6YT4VEZ92AI;F9O+"!S:7IE,BD["B`@("`H M*FEN9F\M/F9PPH*("`@(&-AF4L(&)U9F9E Message-ID: <199901121955.MAA29465@wijiji.santafe.edu> The Modula-2 compiler has been publically available for over three years now, sadly the back end is not based on gcc though. The Modula-2 compiler, ismene simulator (abstract machine) is all GPL'd. The compiler generates ismene code, and i*86 code with pentium optimizations. It seems to me that the right thing to do is to convert this Modula-2 compiler into a GCC front end. Would you be interested in working on that--or at least, would you cooperate with doing it that way? From gaius@glam.ac.uk Wed Jan 13 05:25:00 1999 From: gaius@glam.ac.uk (Gaius Mulley) Date: Wed, 13 Jan 1999 05:25:00 -0000 Subject: {Many thanks for the binutils package} References: <95091916021341@glam.ac.uk> <199901121955.MAA29465@wijiji.santafe.edu> <199901121955.MAA29465@wijiji.santafe.edu> Message-ID: > The Modula-2 compiler has been publically available for over three years > now, sadly the back end is not based on gcc though. The Modula-2 compiler, > ismene simulator (abstract machine) is all GPL'd. The compiler generates > ismene code, and i*86 code with pentium optimizations. > > > > It seems to me that the right thing to do is to convert this Modula-2 > compiler into a GCC front end. Would you be interested in working on > that--or at least, would you cooperate with doing it that way? yes, you're right and yes I'd be interested in helping to do this work. Which release of gcc should I examine? Perhaps looking at GNU ADA would be a good starting point? cheers Gaius --- Gaius Mulley University of Glamorgan gaius@glam.ac.uk Tel: 01443 482279 "I previously had IE4/NT4 on the same box and by comparison the combination of Linux/Nagivator ran at least 30-40% faster when rendering simple HTML + graphics", Josh Cohen, Microsoft (8/98) From kk@ddeorg.soft.net Sat Jan 30 02:59:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Sat, 30 Jan 1999 02:59:00 -0000 Subject: Problems with the GNU linker on mips... Message-ID: <199901301059.QAA11917@bombay.ddeorg.soft.net> Dear all, I am trying to get the GNU linker working for my MIPS(R4400) based system running the SVR4.2 UNIX on the Supermax Business Server from Dansk Data Electronik (DDE). It is one of the MIPS ABI compliant , with IRIX* , SINIX etc... (refer http://www.mipsabi.org ). I am using the egcs-2.91.57 19980901 (egcs-1.1 release) gcc and g++ compilers. As of now I have got a port that used my native ld. (the Edinberg portable one). I had written to the list about my problems with the GNU linker to which Ian replied (Many thanks !!) I have put an entry like this below in mu configure.tgt under gas-990118/ld mips-dde-sysv4*) targ_emul=elf32bsmip ;; in the very beginning of all the mips definitions (to be sure that this one is picked up first).. ian@cygnus.com said: -> --------------- Output of test ------------------------------------- -> ------- -> ../test -> Hello World -> dynamic linker: ./test: unidentifiable procedure reference (address -> = -> 0x40062cd8) -> Killed -> -------------------------------------------------------------------- -> --------- -> - -> I tried to use the readelf utility , but got no clues. -> Try changing the definition of SGI_COMPAT in bfd/elf32-mips.c from 1 -> to 0. By default the linker will generate some form of the Irix -> quickstart relocs. However, you should expect to run into other -> problems, particularly if you try to generate shared libraries -> yourself. -> Ian I applied this change and generated the new linker, and as usual I tried to run the test program . The linking gave me the following message ... ------------- Clip of the compile log of gcc -v t.c -o tt1 ------------------- /usr/local/mips-dde-sysv4.2MP/bin/ld -V -Qy -o tt1 /lib/crt1.o /lib/crti.o /lib/values-Xa.o -L/usr/local/lib/gcc-lib/mips-dde-sysv4.2MP/egcs-2.91.57 -L/usr/local/mips-dde-sysv4.2MP/lib -L/usr/local/lib /var/tmp/ccjlVzGK.o -lgcc -L/usr/lib -lc -lgcc /lib/crtn.o GNU ld version 2.9.4 (with BFD 990118) Supported emulations: elf32bsmip /usr/local/mips-dde-sysv4.2MP/bin/ld: bfd assertion fail .../../gas-990118/bfd/elf32-mips.c:5750 -------------------------------Ends here ------------------------------------ and when I try to run ../tt1 ld.so: ./tt1: relocation error: symbol not found: __rld_map Killed I am not able to trace out this. Any pointers / hints to get out of this problem will be helpful. with best regards Koundinya P.S: ***** I also tried to configure for mips-dde-elf and mips-linux-gnu etc. None of them worked for me. I received some patches from Ralf (ralf@uni-koblenz.de) which were mainly for mips-linux-gnu, which I applied , but could not solve my problems. I have tried almost other permutations and combinations , playing around with configurations and I had no good luck. From ian@cygnus.com Sat Jan 30 10:03:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 30 Jan 1999 10:03:00 -0000 Subject: Problems with the GNU linker on mips... References: <199901301059.QAA11917@bombay.ddeorg.soft.net> Message-ID: <199901301736.MAA19237@subrogation.cygnus.com> Date: Sat, 30 Jan 1999 16:29:54 +0530 From: "Koundinya.K" I applied this change and generated the new linker, and as usual I tried to run the test program . The linking gave me the following message ... ------------- Clip of the compile log of gcc -v t.c -o tt1 ------------------- /usr/local/mips-dde-sysv4.2MP/bin/ld -V -Qy -o tt1 /lib/crt1.o /lib/crti.o /lib/values-Xa.o -L/usr/local/lib/gcc-lib/mips-dde-sysv4.2MP/egcs-2.91.57 -L/usr/local/mips-dde-sysv4.2MP/lib -L/usr/local/lib /var/tmp/ccjlVzGK.o -lgcc -L/usr/lib -lc -lgcc /lib/crtn.o GNU ld version 2.9.4 (with BFD 990118) Supported emulations: elf32bsmip /usr/local/mips-dde-sysv4.2MP/bin/ld: bfd assertion fail .../../gas-990118/bfd/elf32-mips.c:5750 Which assertion is that? There is no assertion on line 5750 of the elf32-mips.cfile here, probably because of the patches you have applied. Looking at the code there may help you figure out the problem. Or it may be unimportant. -------------------------------Ends here ------------------------------------ and when I try to run ../tt1 ld.so: ./tt1: relocation error: symbol not found: __rld_map Killed I am not able to trace out this. Any pointers / hints to get out of this problem will be helpful. Search for "__rld_map" in elf32-mips.c. Some of the associated code is SGI_COMPAT, and some is not. Probably, it all should be. You are probably going to have to do some debugging and programming to get this code to work for you. Ian From kk@ddeorg.soft.net Sun Jan 31 22:25:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Sun, 31 Jan 1999 22:25:00 -0000 Subject: GNU linker on mips Message-ID: <199902010627.LAA05340@bombay.ddeorg.soft.net> Hello Ian, Thanks for the quick response. Yes I have been doing some debugging ( not any programming so far ....). In the mips-elf32.c (bfd) I changed back the SGI_COMPAT to 0 ( which I had changed it to 1) I have a utility called truss (trace system calls and signals). I wrote a test program (t.c).and then I id 2 tests... 1) compiled using the native ld and GNU assembler Result -- No problem (as usual) $gcc -v t.c -o tt $truss tt execve("./tt", 0x7FFFBAF0, 0x7FFFBAF8) argc = 1 open("/usr/lib/libc.so.patch", O_RDONLY, 01) = 3 fxstat(2, 3, 0x7FFFB6E8) = 0 mmap(0x00000000, 8192, PROT_READ, MAP_SHARED, 3, 0) = 0x400C0000 mmap(0x00000000, 109920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40100000 mmap(0x4011A000, 3376, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 40960) = 0x4011A000 munmap(0x4010C000, 57344) = 0 close(3) = 0 ioctl(1, TCGETA, 0x7FFFB91C) Err#25 ENOTTY fxstat(2, 1, 0x7FFFB964) = 0 brk(0x004147D0) = 0 Hello.... write(1, " H e l l o . . . .\n", 10) = 10 _exit(10) 2)compiled using the GNU ld and gnu assembler RESULT -- Problem -- dynamic linker: ./tt: unidentifiable procedure reference (address = 0x40062cd8) Killed $gcc -v t.c -o tt $truss tt execve("./tt", 0x7FFFBAF8, 0x7FFFBB00) argc = 1 open("/usr/lib/libc.so.patch", O_RDONLY, 01) = 3 fxstat(2, 3, 0x7FFFB6E8) = 0 mmap(0x00000000, 8192, PROT_READ, MAP_SHARED, 3, 0) = 0x400C0000 mmap(0x00000000, 109920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40100000 mmap(0x4011A000, 3376, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 40960) = 0x4011A000 munmap(0x4010C000, 57344) = 0 close(3) = 0 ioctl(1, TCGETA, 0x7FFFB91C) Err#25 ENOTTY fxstat(2, 1, 0x7FFFB964) = 0 brk(0x100040A0) = 0 dynamic linker: tt: unidentifiable procedure reference (address = 0x40062cd8) write(2, " d y n a m i c l i n k".., 78) = 78 getpid() = 18404 [ 18403 ] *** process killed *** ----------------------------------------------------------------------------- - Does this give any pointers to the problem... Thanks for all the help and information in advance. With best regards Koundinya P.S: I need to configure as (rather I have added this in my configure.tgt mips-dde-sysv4*) targ_emul=elf32bsmip ;; My native ld sets the ENTRY to __start as on IRIX Systems. From ralf@uni-koblenz.de Tue Feb 2 18:08:00 1999 From: ralf@uni-koblenz.de (ralf@uni-koblenz.de) Date: Tue, 02 Feb 1999 18:08:00 -0000 Subject: GNU linker on mips References: <199902010627.LAA05340@bombay.ddeorg.soft.net> <199902010627.LAA05340@bombay.ddeorg.soft.net> Message-ID: <19990202114543.F1596@uni-koblenz.de> On Mon, Feb 01, 1999 at 11:57:54AM +0530, Koundinya.K wrote: > My native ld sets the ENTRY to __start as on IRIX Systems. Can anybody explain why IRIX uses a non-zero value for __start? That triggered quite a number of bugs in basically every piece of software that tries to load ELF binaries into memory ... So far we're just doing the same thing for mips*-*-linux but there not really a good reason. Ralf From ian@cygnus.com Tue Feb 2 18:56:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 02 Feb 1999 18:56:00 -0000 Subject: GNU linker on mips References: <19990202114543.F1596@uni-koblenz.de> Message-ID: <199902030237.VAA28892@subrogation.cygnus.com> Date: Tue, 2 Feb 1999 11:45:43 +0100 From: ralf@uni-koblenz.de On Mon, Feb 01, 1999 at 11:57:54AM +0530, Koundinya.K wrote: > My native ld sets the ENTRY to __start as on IRIX Systems. Can anybody explain why IRIX uses a non-zero value for __start? That triggered quite a number of bugs in basically every piece of software that tries to load ELF binaries into memory ... So far we're just doing the same thing for mips*-*-linux but there not really a good reason. I don't know of any system which uses a zero value for __start. Most systems protect the zero page to catch null pointer dereferences. Why do you expect __start to be zero? What sorts of problems are you seeing? Ian From ralf@uni-koblenz.de Thu Feb 4 19:11:00 1999 From: ralf@uni-koblenz.de (ralf@uni-koblenz.de) Date: Thu, 04 Feb 1999 19:11:00 -0000 Subject: GNU linker on mips References: <19990202114543.F1596@uni-koblenz.de> <199902030237.VAA28892@subrogation.cygnus.com> <199902030237.VAA28892@subrogation.cygnus.com> Message-ID: <19990203130347.A5244@uni-koblenz.de> On Tue, Feb 02, 1999 at 09:37:17PM -0500, Ian Lance Taylor wrote: > I don't know of any system which uses a zero value for __start. Most > systems protect the zero page to catch null pointer dereferences. Why > do you expect __start to be zero? What sorts of problems are you > seeing? Sorry, braino on my side. I meant SHLIB_TEXT_START_ADDR, not __start. MIPS systems typically use 0x5ffe0000, not zero and that triggered kernel bugs, glibc bugs and some undesireable behaviour in the Linux kernel, glibc dynamic linker and others I forgot. It did not trigger any bfd / gas / binutils bugs. Ralf From ian@cygnus.com Thu Feb 4 19:28:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 04 Feb 1999 19:28:00 -0000 Subject: GNU linker on mips References: <19990203130347.A5244@uni-koblenz.de> Message-ID: <199902050317.WAA02402@subrogation.cygnus.com> Date: Wed, 3 Feb 1999 13:03:47 +0100 From: ralf@uni-koblenz.de On Tue, Feb 02, 1999 at 09:37:17PM -0500, Ian Lance Taylor wrote: > I don't know of any system which uses a zero value for __start. Most > systems protect the zero page to catch null pointer dereferences. Why > do you expect __start to be zero? What sorts of problems are you > seeing? Sorry, braino on my side. I meant SHLIB_TEXT_START_ADDR, not __start. MIPS systems typically use 0x5ffe0000, not zero and that triggered kernel bugs, glibc bugs and some undesireable behaviour in the Linux kernel, glibc dynamic linker and others I forgot. It did not trigger any bfd / gas / binutils bugs. Ah. I don't know why SHLIB_TEXT_START_ADDR should be anything other than zero. It seems to me that making it zero is a bit more natural for the RELATIVE relocs, but I don't think MIPS ELF has a RELATIVE reloc anyhow, and of course it shouldn't really matter anyhow. If it is more convenient for the Linux kernel to make SHLIB_TEXT_START_ADDR 0 for MIPS GNU/Linux, then I can't see any reason not to do it. Ian From kk@ddeorg.soft.net Thu Feb 4 23:28:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Thu, 04 Feb 1999 23:28:00 -0000 Subject: GNU Linker on MIPS - Interesting observation... Message-ID: <199902050733.NAA06926@bombay.ddeorg.soft.net> Dear Ian & Ralf, First of all thanks for all your responses to mails. I got the most recent binutils compiled and running here on my MIPS System. As again I took the famous "hello world" test program compiled it to test the linker. I got the error.... dynamic linker: ./test: unidentifiable procedure reference (address = 0x40062cd8) Killed Then after trying to trace at the system call level using the truss utility that I have , I added an explicit _exit(0) in the test program and compiled it. To my big surprise program executed normally Which meant that the linker did not get killed. For the first time I could see the linker produce output on my system. test.c ****** main() { printf("Hello World !!\n"); _exit(0); } gcc -v test.c -o test ------------ log of test.c compilation ## Earlier stuff not shown ------------- /usr/local/mips-dde-sysv4.2MP/bin/as -v -o /var/tmp/ccEYpuNk.o /var/tmp/ccmtjbG6.s GNU assembler version 990118 (mips-dde-elf) using BFD version 990118 /usr/local/mips-dde-sysv4.2MP/bin/ld -V -Qy -o test /lib/crt1.o /lib/crti.o /lib/values-Xa.o -L/usr/local/lib/gcc-lib/mips-dde-sysv4.2MP/egcs-2.91.57 -L/usr/local/lib /var/tmp/ccEYpuNk.o -lgcc -L/usr/lib -lc -lgcc /lib/crtn.o GNU ld version 2.9.4 (with BFD 990118) Supported emulations: elf32bsmip -------------------Log ends here -------------------------------------------- -- star:1185 [/tmp] ./test Hello World !! Could there be any problem with the start up files that are being used ???. I would be happy If you could provide me with any comments of your's. Thanks again in advance. With best regards Koundinya P.S: I think i am Missing out one some of the discussion that went on ...I have not received any mail like this... ian@cygnus.com said: -> On Tue, Feb 02, 1999 at 09:37:17PM -0500, Ian Lance Taylor wrote: -> > I don't know of any system which uses a zero value for __start. -> Most -> > systems protect the zero page to catch null pointer dereferences. -> Why -> > do you expect __start to be zero? What sorts of problems are you -> > seeing? Has this mail been posted to the gas2 or bfd lists. Or is it between You people.. I did not receive any mails regarding this discussion . You could probably forward those mails to me if you don't mind. From kk@ddeorg.soft.net Sat Feb 6 01:47:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Sat, 06 Feb 1999 01:47:00 -0000 Subject: Debugging the GNU Linker on MIPS... Message-ID: <199902060952.PAA09616@bombay.ddeorg.soft.net> Dear all, I would like to know how one can debug the linker at source level. I have not done this type of debugging before. How are there tools usually debugged. I am not able to figure out how it is possible to debug a linker. Is there any special way for debugging there ?? Any help or information will help me for making the GNU linker work on my MIPS based system With best regards Koundinya From ian@cygnus.com Sat Feb 6 08:30:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 06 Feb 1999 08:30:00 -0000 Subject: Debugging the GNU Linker on MIPS... References: <199902060952.PAA09616@bombay.ddeorg.soft.net> Message-ID: <199902061605.LAA26156@subrogation.cygnus.com> Date: Sat, 06 Feb 1999 15:22:25 +0530 From: "Koundinya.K" I would like to know how one can debug the linker at source level. I have not done this type of debugging before. How are there tools usually debugged. I am not able to figure out how it is possible to debug a linker. Is there any special way for debugging there ?? The tool you need is called gdb. There's nothing special about the linker; debugging it is just like debugging any other complex program. If you've really never used a source level debugger, then you have a pretty steep learning curve ahead of you. Ian From kk@ddeorg.soft.net Thu Feb 11 06:48:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Thu, 11 Feb 1999 06:48:00 -0000 Subject: GNU Linker and mips... Message-ID: <199902111430.UAA16259@bombay.ddeorg.soft.net> Hi, Here is some info on my debugging the GNU linker with gdb as suggested. I just took the small test program of "hello" to avoid those thousands of assembly instructions. As you know the output that I get is hello dynamic linker: ./tt: unidentifiable procedure reference (address = 0x40062cd8) Killed Now what is there at this location and from where is this message coming... O.K From the assembly I could see the following... 0x40062cd8 [_exithandle+0x6c]: lw %t0,0(%s) This message is coming from the function _binder when a call to this function is made as ... _binder(0x23,0x40062cd8,0x400bf2fo,0x40052fd0) I do have access to DDE-MIPS SVR4.2 Sources here and that is how I could locate where this message is coming from. I am attaching the file binder.c which is part of the libc and rtld for mipsr4000. The base for the mips-dde-sysv4.2MP port seems to have mainly come from i386 as base. - ---- Some clip from that (although I am attaching that file at end ) ----- unsigned long _binder( unsigned long sym_index, unsigned long pc) { struct rt_private_map *nlm, *first_lm, *lm; char *symname; - - - - - - - - - - - - Some line go here ..... /* Note that since the MIPS ABI doesn't provide a means for passing * lm from the stub routines, so we must get this information * someplace else. Here we just start with the head of the list * which is stored in the global variable _ld_loaded. This may * not be correct for objects which have DT_SYMBOLIC set. * FIXME! */ lm = _rt_address_to_lm(_ld_loaded,pc); if (!lm) { _rtfprintf(2, "%s: %s: unidentifiable procedure reference (addre ss = 0x%x)\n",(char*) _rt_name,_proc_name,pc); (void)_rtkill(_rtgetpid(), SIGKILL); } - ------------------ End of the clip .. later stuff not here - ------------------- So here is the message that I am getting . But how and why is it happening , I could not think. Any pointers on this.... Could there be any problems with the start up file like crti, crt1 and crtn used. This is how the linking is done ... -------------------------------------------------------------------------- /usr/local/mips-dde-sysv4.2MP/bin/ld /usr/lib/ld.so.1 /usr/local/mips-dde-sysv4.2MP/lib/crt1.o /usr/local/mips-dde-sysv4.2MP/lib/crti.o /usr/local/mips-dde-sysv4.2MP/lib/values-Xa.o -L/usr/local/lib/gcc-lib/mips-dde-sysv4.2MP/egcs-2.91.57 -L/usr/local/mips-dde-sysv4.2MP/lib -L/usr/local/lib /var/tmp/ccrLBNAM.o -lgcc -L/usr/lib -lc -lgcc /usr/local/mips-dde-sysv4.2MP/lib/crtn.o GNU ld version 2.9.4 (with BFD 990118) Supported emulations: elf32bsmip -------------------------------------------------------------------------- Could using the crtbegin and crtend help. Why don't the MIPS targets use them.. Thanks for any help and information in advance. With best regards Koundinya Here is the file binder.c (which is a part of the native libc source )that I am attaching... Thanks for any help in advance. Koundinya From ian@cygnus.com Thu Feb 11 08:20:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 11 Feb 1999 08:20:00 -0000 Subject: GNU Linker and mips... References: <199902111430.UAA16259@bombay.ddeorg.soft.net> Message-ID: <199902111620.LAA00234@subrogation.cygnus.com> Date: Thu, 11 Feb 1999 20:00:02 +0530 From: "Koundinya.K" /* Note that since the MIPS ABI doesn't provide a means for passing * lm from the stub routines, so we must get this information * someplace else. Here we just start with the head of the list * which is stored in the global variable _ld_loaded. This may * not be correct for objects which have DT_SYMBOLIC set. * FIXME! */ lm = _rt_address_to_lm(_ld_loaded,pc); Can you find out what _ld_loaded is initialized to? But how and why is it happening , I could not think. It looks like your dynamic linker expects some sort of structure which the GNU linker is not setting up. Could there be any problems with the start up file like crti, crt1 and crtn used. I doubt it. Could using the crtbegin and crtend help. Why don't the MIPS targets use them.. I doubt this would make any difference either. The Irix targets don't use crtbegin and crtend because the Irix linker has another mechanism for ensuring that the global constructors will run. Your target may need crtbegin and crtend, but using them won't fix the problem you are encountering. Ian From kk@ddeorg.soft.net Thu Feb 18 06:57:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Thu, 18 Feb 1999 06:57:00 -0000 Subject: Problem with GNU Linker on mips... References: <199902111620.LAA00234@subrogation.cygnus.com> Message-ID: <199902181439.UAA13324@bombay.ddeorg.soft.net> Hello, First of all a quick thanks to Ian for the response to my queries. O.K -> Date: Thu, 11 Feb 1999 20:00:02 +0530 -> From: "Koundinya.K" -> -> /* Note that since the MIPS ABI doesn't provide a means for passing -> * lm from the stub routines, so we must get this information -> * someplace else. Here we just start with the head of the list -> * which is stored in the global variable _ld_loaded. This may -> * not be correct for objects which have DT_SYMBOLIC set. -> * FIXME! -> */ -> lm = _rt_address_to_lm(_ld_loaded,pc); -> -> Can you find out what _ld_loaded is initialized to? -> Yes and no , I am not able to watch the elements of the structure. _ld_loaded contains the value 1074495092 and the address of _ld_loaded is 419304. -> It looks like your dynamic linker expects some sort of structure which -> the GNU linker is not setting up. -> -> Could there be any problems with the start up file like crti, crt1 and crtn used. -> -> I doubt it. -> -> Could using the crtbegin and crtend help. Why don't the MIPS targets use them.. -> -> I doubt this would make any difference either. The Irix targets don't -> use crtbegin and crtend because the Irix linker has another mechanism -> for ensuring that the global constructors will run. Your target may -> need crtbegin and crtend, but using them won't fix the problem you are -> encountering. -> -> Yes as you say, I don't think my target requires the crtbegin and end. THen I then realized this when I saw what my native EPC compiler used. It is very similar to IRIX* ------Clip of what my native compiler uses ------------------------------ $cc -Wl,-note -V t.c -o tt EPC ANSI C 3.0.12 Copyright (c) 1991,1992,1993,1994,1995 EPCL. All Rights Reserved Copyright (c) 1990,1991 UNIX System Laboratories, Inc. Copyright (c) 1988 AT&T ecc: C Development Set (ECCS) (3.0.12) Jun 6 1995 acomp: C Development Set (ECCS) (3.0.12) Jun 7 1995 as: (EPC MIPS-2 Compilation Tools) 3.6.3 Apr 11 1995 ld: EPC MIPS-2 Compilation Tools (3.6.6) Apr 11 1995 ld: /opt/epc/ecc/epctools/crt1.o: notice: reading: ELF flags=0x000003 ld: /opt/epc/ecc/epctools/crti.o: notice: reading: ELF flags=0x000003 ld: /opt/epc/ecc/epctools/values-Xt.o: notice: reading: ELF flags=0x000002 ld: t.o: notice: reading: ELF flags=0x000005 ld: /opt/epc/ecc/epctools/crtn.o: notice: reading: ELF flags=0x000002 ld: /usr/ccs/lib/libc.so(libc.so.1): notice: reading: ELF flags=0x10000003 ----------------------------------------------------------------------------- I am still in the process of debugging. I found out something else. I tried to debug one test program. (both using gas) 1) Using gcc and native linker 2) Using gcc and the gnu linker. I) In the first case as usual I don't have any problem. >From the _exithandle() , _fini is called. __________________ Clip of the debugging __________________________________ 0x40062cc8 in _exithandle () 0x40062ccc in _exithandle () 0x40062cd0 in _exithandle () 0x400744 in _fini () 0x400748 in _fini () 0x400750 in _fini () ____________________ Later stuff not shown _________________________ II) How ever in the second case the _fini () is *not* being called . Instead _etext is being called from where on after return to _exithandle -> _cleanup () -> _rtbinder ........ message "unidentifiable procedure reference (address =0x40062cd8 Killed ___________________ Clip of the debugging ___________________________________ 0x40062ccc in _exithandle () 0x40062cd0 in _exithandle () 0x4009c0 in _etext () 0x4009c4 in _etext () 0x4009cc in _etext () 0x4009d0 in _etext () ... ... ... ... ... ... .. .. .. .. .. .. .. 0x4009ec in _etext () 0x40062cd8 in _exithandle () 0x40062cdc in _exithandle () 0x40062ce0 in _exithandle () 0x40062ce4 in _exithandle () 0x40062cc4 in _exithandle () 0x40062cc8 in _exithandle () 0x40062ccc in _exithandle () 0x40062cd0 in _exithandle () 0x400980 in _cleanup () 0x400984 in _cleanup () 0x400988 in _cleanup () 0x40052f60 in _rtbinder () 0x40052f64 in _rtbinder () 0x40052f68 in _rtbinder () ........ ........ dynamic linker: unidentifiable procedure reference (address = 0x40062cd8) killed _____________________Later stuff not shown __________________________________ So I can see that _fini() is not being called , (which I think should be)... Any pointers on this will help me for further debugging. Or may be this could solve the problem , I suppose. Thanks in advance for any help received. With best regards Koundinya From kk@ddeorg.soft.net Sat Feb 20 00:48:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Sat, 20 Feb 1999 00:48:00 -0000 Subject: GNU linker on MIPS and the _etext section .... Message-ID: <199902200847.OAA10979@bombay.ddeorg.soft.net> Dear all and Ian, I have some doubt regarding the _etext section. I am still in the process of debugging the GNU linker. After some hours of debugging last night I found that my runtime linker is getting killed because a call to the _etext is resulting in a procedure linkage table entry for my run time linker. After this all the binder code of the run time linker is called and then the linker gets killed. I don't know how far I am correct. Here is my observation of a test program that I first compiled using gcc and native ld , then compiled again with gcc and gnu ld. 1) gcc and the native ld. (No problem here ) _____________ Earlier Stuff not shown ____________________________________ __________________________________________________________________________ 0x40062ed8 in _exithandle () 0x40062edc in _exithandle () 0x40062ee0 in _exithandle () 0x400744 in _fini () 0x400748 in _fini () 0x400750 in _fini () 0x400754 in _fini () 0x400758 in _fini () 0x40075c in _fini () 0x400760 in _fini () 0x400764 in _fini () 0x400768 in _fini () 0x40076c in _fini () 0x400770 in _fini () 0x40062ee8 in _exithandle () 0x40062eec in _exithandle () 0x40062ef0 in _exithandle () 0x40062ef4 in _exithandle () _________________________ Later stuff not shown _____________________________ _ 2) gcc and GNU ld _________________________________________________________________________ _________________ Earlier Stuff not shown _________________________________ 0x40062ed4 in _exithandle () 0x40062ed8 in _exithandle () 0x40062edc in _exithandle () 0x40062ee0 in _exithandle () 0x4009c0 in _etext () 0x4009c4 in _etext () 0x4009cc in _etext () 0x4009d0 in _etext () 0x4009d4 in _etext () 0x4009d8 in _etext () 0x4009dc in _etext () 0x4009e0 in _etext () 0x4009e4 in _etext () 0x4009e8 in _etext () 0x4009ec in _etext () 0x40062ee8 in _exithandle () 0x40062eec in _exithandle () 0x40062ef0 in _exithandle () 0x40062ef4 in _exithandle () 0x40062ec4 in _exithandle () 0x40062ec8 in _exithandle () 0x40062ecc in _exithandle () 0x40062ed0 in _exithandle () 0x40062ed4 in _exithandle () 0x40062ed8 in _exithandle () 0x40062edc in _exithandle () 0x40062ee0 in _exithandle () 0x400980 in _cleanup () 0x400984 in _cleanup () 0x400988 in _cleanup () 0x40051310 in _rtbinder () 0x40051314 in _rtbinder () after many more steppings I get ... Hello dynamic linker: ./tt1: unidentifiable procedure reference (address = 0x40062ee8) Killed _____________________________________________________________________________ __ I am using gdb for debugging. For gcc + gnu ld combination I am able to step into the _etext function. For the gcc + native ld combination I am not able to get into _etext (). I get a message from gdb like this. _____________________________________________________________________________ __ (gdb) break _etext warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x400778 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. Breakpoint 2 at 0x400778 _____________________________________________________________________________ I would be glad I can get any pointers on these issues and the problem that I am facing. With best regards Koundinya From ian@cygnus.com Sun Feb 21 17:33:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Sun, 21 Feb 1999 17:33:00 -0000 Subject: GNU linker on MIPS and the _etext section .... References: <199902200847.OAA10979@bombay.ddeorg.soft.net> Message-ID: <199902220122.UAA03149@subrogation.cygnus.com> Date: Sat, 20 Feb 1999 14:17:50 +0530 From: "Koundinya.K" I have some doubt regarding the _etext section. _etext is not a section. It is a symbol. It normally marks the end of the .text section. I am still in the process of debugging the GNU linker. After some hours of debugging last night I found that my runtime linker is getting killed because a call to the _etext is resulting in a procedure linkage table entry for my run time linker. Nothing is calling _etext. gdb is seeing a call to some address. It can't find a symbol associated with that address. The address happens to be after _etext, so it decides to call the address _etext plus something. Don't pay any attention to _etext--that's just a red herring resulting from how gdb decides to display addresses. Your program is actually calling into code for which gdb can not find any debugging information. This code is probably in the dynamic linker, or in a shared library. Ian From jeffdbREMOVETHIS@goodnet.com Wed Feb 24 00:03:00 1999 From: jeffdbREMOVETHIS@goodnet.com (Mikey) Date: Wed, 24 Feb 1999 00:03:00 -0000 Subject: ld -r segfaults && make bootstrap fix for i586-cygwin32 Message-ID: <36d2ea6c.476789894@mail.goodnet.com> in .../src/ld/emultempl/pe-em line 446 opened, so registering the symbol as undefined will make a difference. */ + if (!link_info.relocateable) ldlang_add_undef (entry_symbol); } otherwise ld -r segfaults every time I don't know preciscly where in the config files to fix this but in Makefile it would have to be cmp --ignore-initial=137 ld2.exe ld3.exe and -lc needs to be replaced with -lcygwin -lkernel32 From kk@ddeorg.soft.net Tue Mar 2 03:39:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Tue, 02 Mar 1999 03:39:00 -0000 Subject: crt files... Message-ID: <199903021139.RAA10414@bombay.ddeorg.soft.net> Dear ian and all, I am looking for the sources of startup files (crt1, crti , crtn etc) for MIPS based Systems running SVR4.2 . Where can I get them. ? I tried the newlib sources, but could not see any... Thanks in advance for any help. With best regards Koundinya From snowball3@usa.net Tue Mar 2 21:56:00 1999 From: snowball3@usa.net (Mark E.) Date: Tue, 02 Mar 1999 21:56:00 -0000 Subject: .eh_frame problem Message-ID: <199903030556.FAA07970@out5.ibm.net> Could somebody from binutils read the thread archived at http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00547.html . It's a thread about a padding problem with .eh_frame and at least DJGPP. According to the egcs folks, this problem needs to be solved in gas. Are they right? Mark --- Mark Elbrecht snowball3@usa.net http://members.xoom.com/snowball3/ From snowball3@usa.net Wed Mar 3 07:17:00 1999 From: snowball3@usa.net (Mark E.) Date: Wed, 03 Mar 1999 07:17:00 -0000 Subject: .eh_frame problem Message-ID: <199903031517.PAA28568@out2.ibm.net> > Could somebody from binutils read the thread archived at > http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00547.html . It's > a thread about a padding problem with .eh_frame and at least DJGPP. > According to the egcs folks, this problem needs to be solved in gas. Are > they right? I forgot to mention DJGPP (i[34567]-pc-msdosdjgpp) uses COFF. I wonder if .eh_frame should be given flagged like a data section (like .edata and others are) in sec_to_stype_flags and in style_to_sec_flags. Then wouldn't .eh_frame be padded with 0x0 instead of 0x90 (NOP) as it currently is? Mark --- Mark Elbrecht snowball3@usa.net http://members.xoom.com/snowball3/ From ian@cygnus.com Wed Mar 3 16:37:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 03 Mar 1999 16:37:00 -0000 Subject: crt files... References: <199903021139.RAA10414@bombay.ddeorg.soft.net> Message-ID: <199903040037.QAA03046@rtl.cygnus.com> Date: Tue, 02 Mar 1999 17:09:03 +0530 From: "Koundinya.K" I am looking for the sources of startup files (crt1, crti , crtn etc) for MIPS based Systems running SVR4.2 . Where can I get them. ? I tried the newlib sources, but could not see any... These files are normally highly system specific, and in particular are tied to the details of your libc. They are provided by glibc. If you are not using glibc, then you probably must use the files provided by your system, and you would have to ask your vendor for sources (or you could just disassemble the files--they're normally small). Ian From ian@cygnus.com Wed Mar 3 16:53:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 03 Mar 1999 16:53:00 -0000 Subject: .eh_frame problem References: <199903030556.FAA07970@out5.ibm.net> Message-ID: <199903040053.QAA03202@rtl.cygnus.com> From: "Mark E." Date: Wed, 3 Mar 1999 00:56:54 -0500 Could somebody from binutils read the thread archived at http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00547.html . It's a thread about a padding problem with .eh_frame and at least DJGPP. According to the egcs folks, this problem needs to be solved in gas. Are they right? I think it would be more reliable to fix this in gcc, but it could also be fixed in gas. The basic problem is that gas doesn't know whether a section contains code or not. Thus it has to guess about how to align the contents of the section. I forgot to mention DJGPP (i[34567]-pc-msdosdjgpp) uses COFF. I wonder if .eh_frame should be given flagged like a data section (like .edata and others are) in sec_to_stype_flags and in style_to_sec_flags. Then wouldn't .eh_frame be padded with 0x0 instead of 0x90 (NOP) as it currently is? I doubt it, since I think that djgpp doesn't use BFD_ASSEMBLER. If you look at gas/config/tc-i386.h at md_maybe_text, you will see how gas guesses whether to pad with 0x90 or 0. What does egcs say in the .section directive for .eh_frame for djgpp? Is there enough information there for the assembler to somehow know that the section contains data rather than code? If there is, then we should figure out how to get that information to md_maybe_text, as should already work for the BFD_ASSEMBLER version of gas. Ian From snowball3@usa.net Wed Mar 3 21:00:00 1999 From: snowball3@usa.net (Mark E.) Date: Wed, 03 Mar 1999 21:00:00 -0000 Subject: .eh_frame problem References: <199903030556.FAA07970@out5.ibm.net> <199903040053.QAA03202@rtl.cygnus.com> Message-ID: <199903040500.FAA54290@out4.ibm.net> > section contains data rather than code? If there is, then we should > figure out how to get that information to md_maybe_text, as should already > work for the BFD_ASSEMBLER version of gas. The problem does goes away when using BFD_ASSEMBLER gas. But I'll take a look and see if there is a solution for non-BFD_ASSEMBLER gas. We'd use BFD_ASSEMBER gas in 2.9.1 but if you'll recall it has that bug I reported and you fixed in late October where incorrect fixups are written out making the object files unusable. Mark --- Mark Elbrecht snowball3@usa.net http://members.xoom.com/snowball3/ From snowball3@usa.net Wed Mar 3 21:15:00 1999 From: snowball3@usa.net (Mark E.) Date: Wed, 03 Mar 1999 21:15:00 -0000 Subject: .eh_frame problem References: <199903030556.FAA07970@out5.ibm.net> <199903040053.QAA03202@rtl.cygnus.com> Message-ID: <199903040515.FAA105708@out2.ibm.net> > I doubt it, since I think that djgpp doesn't use BFD_ASSEMBLER. If > you look at gas/config/tc-i386.h at md_maybe_text, you will see how > gas guesses whether to pad with 0x90 or 0. > Here's the code: #ifdef BFD_ASSEMBLER #define md_maybe_text() \ ((bfd_get_section_flags (stdoutput, now_seg) & SEC_CODE) != 0) #else #define md_maybe_text() \ (now_seg != data_section && now_seg != bss_section) #endif It seems to me, to parallel the BFD_ASSEMBER version, that the !BFD_ASSEMBER version should be something like: #define md_maybe_text() (now_seg == text_section) Mark --- Mark Elbrecht snowball3@usa.net http://members.xoom.com/snowball3/ From ian@cygnus.com Thu Mar 4 14:32:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 04 Mar 1999 14:32:00 -0000 Subject: .eh_frame problem References: <199903040515.FAA105708@out2.ibm.net> Message-ID: <199903042231.OAA12086@rtl.cygnus.com> From: "Mark E." Date: Thu, 4 Mar 1999 00:15:52 -0500 Here's the code: #ifdef BFD_ASSEMBLER #define md_maybe_text() \ ((bfd_get_section_flags (stdoutput, now_seg) & SEC_CODE) != 0) #else #define md_maybe_text() \ (now_seg != data_section && now_seg != bss_section) #endif It seems to me, to parallel the BFD_ASSEMBER version, that the !BFD_ASSEMBER version should be something like: #define md_maybe_text() (now_seg == text_section) That would not be parallel, since when using COFF or ELF it is possible for a section other than text_section to contain code. This will happen if you compile with -ffunction-sections, for example. Ian From hjl@lucon.org Tue Mar 9 08:50:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Tue, 09 Mar 1999 08:50:00 -0000 Subject: binutils bug: config.guess (fwd) Message-ID: Forwarded message: From carlo@runaway.xs4all.nl Tue Mar 9 08:50:00 1999 From: carlo@runaway.xs4all.nl (Carlo Wood) Date: Tue, 09 Mar 1999 08:50:00 -0000 Subject: binutils bug: config.guess Message-ID: <199903091509.QAA03972@jolan.ppro> Hiya, when trying to compile binutils-2.9.1.0.22b, I ran into a problem with config.guess. I have "." in my PATH, and it seems that makes config.guess fail to execute `ld'. It tries to execute the directory ld/ in binutils. Adding a PATH=/bin:/usr/bin helped for me, which is prove that this is indeed the problem. I know I shouldn't have a "." in my path before /usr/bin, but I am sure I am not the only one that has it any way :). Here's an strace output: /usr/src/binutils/binutils-2.9.1.0.22b>strace -ff config.guess 2>&1 | grep exec execve("./config.guess", ["config.guess"], [/* 39 vars */]) = 0 [pid 3935] execve("/bin/uname", ["uname", "-m"], [/* 39 vars */]) = 0 [pid 3937] execve("/bin/uname", ["uname", "-r"], [/* 39 vars */]) = 0 [pid 3939] execve("/bin/uname", ["uname", "-s"], [/* 39 vars */]) = 0 [pid 3941] execve("/bin/uname", ["uname", "-v"], [/* 39 vars */]) = 0 [pid 3943] execve("/usr/bin/ld", ["ld", "--help"], [/* 39 vars */]) = 0 [pid 3946] execve("/bin/sed", ["sed", "-ne", "/supported emulations:/!d\n\t\t\t"...], [/* 39 vars */]) = 0 [pid 3948] execve("/bin/grep", ["grep", "supported emulations:"], [/* 39 vars */]) = 0 [pid 3949] execve("/bin/cat", ["cat"], [/* 39 vars */]) = 0 [pid 3950] execve("/usr/bin/cc", ["cc", "dummy.c", "-o", "dummy"], [/* 39 vars */]) = 0 [pid 3951] execve("/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/cpp", ["/usr/local/egcs/lib/gcc-lib/i686"..., "-lang-c", "-undef", "-D__GNUC__=2", "-D__GNUC_MINOR__=91", "-D__ELF__", "-Dunix", "-Di386", "-D__i386__", "-Dlinux", "-D__ELF__", "-D__unix__", "-D__i386__", "-D__i386__", "-D__linux__", "-D__unix", ...], [/* 41 vars */]) = 0 [pid 3952] execve("/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/cc1", ["/usr/local/egcs/lib/gcc-lib/i686"..., "/tmp/cc1xxCly.i", "-quiet", "-dumpbase", "dummy.c", "-o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = 0 [pid 3953] execve("./as", ["as", "-Qy", "-o", "/tmp/ccBPeacv.o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3953] execve("/home/carlo/bin/as", ["as", "-Qy", "-o", "/tmp/ccBPeacv.o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3953] execve("/usr/local/bin/as", ["as", "-Qy", "-o", "/tmp/ccBPeacv.o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3953] execve("/bin/as", ["as", "-Qy", "-o", "/tmp/ccBPeacv.o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3953] execve("/usr/bin/as", ["as", "-Qy", "-o", "/tmp/ccBPeacv.o", "/tmp/ccsq9UDZ.s"], [/* 41 vars */]) = 0 [pid 3954] execve(ptrace: umoven: Input/output error [pid 3955] execve("./ld", ["./ld", "-m", "elf_i386", "-dynamic-linker", "/lib/ld-linux.so.2", "-o", "dummy", "/usr/lib/crt1.o", "/usr/lib/crti.o", "/usr/local/egcs/lib/gcc-lib/i686"..., "-L/usr/local/egcs/lib/gcc-lib/i6"..., "-L/usr/local/egcs/i686-pc-linux-"..., "-L/usr/local/egcs/lib", "/tmp/ccBPeacv.o", "-lgcc", "-lc", ...], [/* 43 vars */]) = -1 EACCES (Permission denied) [pid 3955] write(2, "collect2: executing ld: Permissi"..., 42) = 42 [pid 3956] execve("/bin/rm", ["rm", "-f", "dummy.c", "dummy"], [/* 39 vars */]) = 0 [pid 3961] execve("/bin/sed", ["sed", "-n", "s/.*NeXT Mach \\([0-9]*\\).*/\\1"...], [/* 39 vars */]) = 0 [pid 3957] execve("/bin/cat", ["cat"], [/* 39 vars */]) = 0 [pid 3962] execve("/usr/bin/cc", ["cc", "dummy.c", "-o", "dummy"], [/* 39 vars */]) = 0 [pid 3963] execve("/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/cpp", ["/usr/local/egcs/lib/gcc-lib/i686"..., "-lang-c", "-undef", "-D__GNUC__=2", "-D__GNUC_MINOR__=91", "-D__ELF__", "-Dunix", "-Di386", "-D__i386__", "-Dlinux", "-D__ELF__", "-D__unix__", "-D__i386__", "-D__i386__", "-D__linux__", "-D__unix", ...], [/* 41 vars */]) = 0 [pid 3964] execve("/usr/local/egcs/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.60/cc1", ["/usr/local/egcs/lib/gcc-lib/i686"..., "/tmp/cc5ljYJi.i", "-quiet", "-dumpbase", "dummy.c", "-o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = 0 [pid 3965] execve("./as", ["as", "-Qy", "-o", "/tmp/cc1tE1lp.o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3965] execve("/home/carlo/bin/as", ["as", "-Qy", "-o", "/tmp/cc1tE1lp.o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3965] execve("/usr/local/bin/as", ["as", "-Qy", "-o", "/tmp/cc1tE1lp.o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3965] execve("/bin/as", ["as", "-Qy", "-o", "/tmp/cc1tE1lp.o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = -1 ENOENT (No such file or directory) [pid 3965] execve("/usr/bin/as", ["as", "-Qy", "-o", "/tmp/cc1tE1lp.o", "/tmp/ccnnWTYj.s"], [/* 41 vars */]) = 0 [pid 3966] execve(ptrace: umoven: Input/output error [pid 3967] execve("./ld", ["./ld", "-m", "elf_i386", "-dynamic-linker", "/lib/ld-linux.so.2", "-o", "dummy", "/usr/lib/crt1.o", "/usr/lib/crti.o", "/usr/local/egcs/lib/gcc-lib/i686"..., "-L/usr/local/egcs/lib/gcc-lib/i6"..., "-L/usr/local/egcs/i686-pc-linux-"..., "-L/usr/local/egcs/lib", "/tmp/cc1tE1lp.o", "-lgcc", "-lc", ...], [/* 43 vars */]) = -1 EACCES (Permission denied) [pid 3967] write(2, "collect2: executing ld: Permissi"..., 42) = 42 [pid 3968] execve("/bin/rm", ["rm", "-f", "dummy.c", "dummy"], [/* 39 vars */]) = 0 While you're at it, I found another problem with config.guess a while ago: I can imagine that someone doesn't have a 'cc', but only a 'gcc'. If you don't set CC in that case, config.guess also fails, a bit weird (and confusing) for a GNU package. -- Carlo Wood PS Even if you fix config.guess, then configure still fails: /usr/src/binutils/binutils-2.9.1.0.22b>./configure Configuring for a i686-pc-linux-gnu host. Created "Makefile" in /usr/src/binutils/binutils-2.9.1.0.22b using "mt-frag" collect2: ld returned 33 exit status *** The command 'gcc -o conftest -g -O2 conftest.c' failed. *** You must set the environment variable CC to a working compiler. -- H.J. Lu (hjl@gnu.org) From joel@OARcorp.com Thu Mar 11 11:26:00 1999 From: joel@OARcorp.com (joel@OARcorp.com) Date: Thu, 11 Mar 1999 11:26:00 -0000 Subject: PowerPC objdump bug report Message-ID: Jennifer and I have seen this bug for a while now in a variety of combinations of gcc and egcs and various binutils versions. The following results in an undesirable object dump. Tools: egcs 1.1b binutils 2.9.1.0.22b newlib 1.8.0 Host: RedHat 5.2 Commands: powerpc-rtems-gcc -c test.c powerpc-rtems-objectdump -d test.o Where test.c is int main(int ignored) { switch ( ignored ) { case 0: return 1; case 5: return 3; case 6: return 2; case 7: return 23; case 9: return 10; default: return -1; } } Produces the following obect dump around the switch. It looks like if the switch is smaller, the problem goes away. 3c: 7d 49 03 a6 mtctr r10 40: 4e 80 04 20 bctr 00000044 <.L3>: 44: 38 60 00 01 48 00 00 28 8`..H..( 0000004c <.L4>: 4c: 38 60 00 03 48 00 00 20 8`..H.. 00000054 <.L5>: 54: 38 60 00 02 48 00 00 18 8`..H... 0000005c <.L6>: 5c: 38 60 00 17 48 00 00 10 8`..H... 00000064 <.L7>: 64: 38 60 00 0a 48 00 00 08 8`..H... 0000006c <.L8>: 6c: 38 60 ff ff 80 01 00 14 7c 08 03 a6 38 21 00 10 8`......|...8!.. 7c: 4e 80 00 20 N.. --joel Joel Sherrill Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From ian@zembu.com Wed Mar 24 08:01:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Wed, 24 Mar 1999 08:01:00 -0000 Subject: Snapshots running again Message-ID: <19990324160111.6846.qmail@comton.airs.com> I'm happy to report that Ken has fixed the snapshot generation problems, and that binutils snapshots are once again available from ftp://ftp.cygnus.com/private/gas . Ian From Franz.Sirl-kernel@lauterbach.com Wed Mar 24 15:38:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Wed, 24 Mar 1999 15:38:00 -0000 Subject: make check problems on powerpc-unknown-linux-gnu Message-ID: <4.2.0.32.19990325002220.03ae7f00@mail.lauterbach.com> Hi, I just tried gas-990324 on powerpc-unknown-linux-gnu (linux-2.2.4, glibc-2.1.1pre1, egcs-1.1.2) and make check showed the follwing 3 problems: Running /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/checks.exp ... /home/fsirl/BUILD/gas-990324/ld/../gas/as-new -o tmpdir/asm.o /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/asm.s /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/asm.s: Assembler messages: /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/asm.s:11: Error: Expected comma after symbol-name: rest of line ignored. /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/asm.s:11: Error: Rest of line ignored. First ignored character is `0'. ERROR: /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-checks/asm.s: assembly failed Running /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-selective/selective.exp ... gcc -w -O2 -ffunction-sections -fdata-sections -B/home/fsirl/BUILD/gas-990324/ld/tmpdir/gas/ -I/home/fsirl/BUILD/gas-990324/ld/testsuite/ld-selecti ve -g -O2 -c /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-selective/1.c -o tmpdir/1.o cc1: Invalid option `-fdata-sections' ERROR: /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-selective/1.c: compilation failed Running /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/shared.exp ... gcc -fpic gcc: No input files gcc -g -O2 -B/home/fsirl/BUILD/gas-990324/ld/tmpdir/gas/ -I/home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared -g -O2 -c /home/fsirl/BUILD/gas-990 324/ld/testsuite/ld-shared/main.c -o tmpdir/mainnp.o gcc -g -O2 -B/home/fsirl/BUILD/gas-990324/ld/tmpdir/gas/ -I/home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared -g -O2 -c /home/fsirl/BUILD/gas-990 324/ld/testsuite/ld-shared/sh1.c -o tmpdir/sh1np.o gcc -g -O2 -B/home/fsirl/BUILD/gas-990324/ld/tmpdir/gas/ -I/home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared -g -O2 -c /home/fsirl/BUILD/gas-990 324/ld/testsuite/ld-shared/sh2.c -o tmpdir/sh2np.o /home/fsirl/BUILD/gas-990324/ld/ld-new -o tmpdir/shnp.so -shared tmpdir/sh1np.o tmpdir/sh2np.o /home/fsirl/BUILD/gas-990324/ld/ld-new -m elf32ppc -o tmpdir/shnp -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/ppc -redhat-linux/egcs-2.91.66/crtbegin.o -rpath tmpdir tmpdir/mainnp.o tmpdir/shnp.so /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a -lc /usr /lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/crtend.o /usr/lib/crtn.o tmpdir/shnp >tmpdir/shnp.out diff tmpdir/shnp.out /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/shared.dat PASS: shared (non PIC) /home/fsirl/BUILD/gas-990324/ld/ld-new -o tmpdir/shnp.so -shared -T /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/elf-offset.ld tmpdir/sh1np. o tmpdir/sh2np.o /home/fsirl/BUILD/gas-990324/ld/ld-new -m elf32ppc -o tmpdir/shnp -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/ppc -redhat-linux/egcs-2.91.66/crtbegin.o -rpath tmpdir tmpdir/mainnp.o tmpdir/shnp.so /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a -lc /usr /lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/crtend.o /usr/lib/crtn.o tmpdir/shnp >tmpdir/shnp.out tmpdir/shnp: error in loading shared libraries: tmpdir/shnp.so: program headers not contained in any loaded segment FAIL: shared (non PIC, load offset) On the last on the only special thing about shnp.so I noticed is the following readelf output: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x00100000 0x00100000 0x017d0 0x017d0 RWE 0x10000 DYNAMIC 0x01176c 0x0010176c 0x0010176c 0x00050 0x00050 RW 0x4 AFAI remember there are usually 2 LOAD entries here, or? Hope this helps, Franz. From ian@zembu.com Wed Mar 24 19:48:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Wed, 24 Mar 1999 19:48:00 -0000 Subject: make check problems on powerpc-unknown-linux-gnu References: <4.2.0.32.19990325002220.03ae7f00@mail.lauterbach.com> Message-ID: <199903250345.TAA22602@rtl.cygnus.com> Date: Thu, 25 Mar 1999 00:36:05 +0100 From: Franz Sirl Running /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/shared.exp ... /home/fsirl/BUILD/gas-990324/ld/ld-new -o tmpdir/shnp.so -shared -T /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/elf-offset.ld tmpdir/sh1np. o tmpdir/sh2np.o /home/fsirl/BUILD/gas-990324/ld/ld-new -m elf32ppc -o tmpdir/shnp -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/ppc -redhat-linux/egcs-2.91.66/crtbegin.o -rpath tmpdir tmpdir/mainnp.o tmpdir/shnp.so /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a -lc /usr /lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/crtend.o /usr/lib/crtn.o tmpdir/shnp >tmpdir/shnp.out tmpdir/shnp: error in loading shared libraries: tmpdir/shnp.so: program headers not contained in any loaded segment FAIL: shared (non PIC, load offset) This one is the only serious error. It's worth investigating why this is happening. Do other people using PowerPC GNU/Linux see this as well? On the last on the only special thing about shnp.so I noticed is the following readelf output: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x00100000 0x00100000 0x017d0 0x017d0 RWE 0x10000 DYNAMIC 0x01176c 0x0010176c 0x0010176c 0x00050 0x00050 RW 0x4 AFAI remember there are usually 2 LOAD entries here, or? Yes, there usually are. However, it is not a requirement. Ian From Franz.Sirl-kernel@lauterbach.com Thu Mar 25 02:35:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 25 Mar 1999 02:35:00 -0000 Subject: make check problems on powerpc-unknown-linux-gnu References: <199903250345.TAA22602@rtl.cygnus.com> Message-ID: <99032511382700.00872@ns1102.munich.netsurf.de> Am Thu, 25 Mar 1999 schrieb Ian Lance Taylor: >Date: Thu, 25 Mar 1999 00:36:05 +0100 > From: Franz Sirl > > Running /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/shared.exp ... > > /home/fsirl/BUILD/gas-990324/ld/ld-new -o tmpdir/shnp.so -shared -T > /home/fsirl/BUILD/gas-990324/ld/testsuite/ld-shared/elf-offset.ld tmpdir/sh1np. > o tmpdir/sh2np.o > /home/fsirl/BUILD/gas-990324/ld/ld-new -m elf32ppc -o tmpdir/shnp > -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o > /usr/lib/gcc-lib/ppc > -redhat-linux/egcs-2.91.66/crtbegin.o -rpath tmpdir tmpdir/mainnp.o > tmpdir/shnp.so /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a -lc /usr > /lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/libgcc.a > /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/crtend.o /usr/lib/crtn.o > tmpdir/shnp >tmpdir/shnp.out > tmpdir/shnp: error in loading shared libraries: tmpdir/shnp.so: program > headers not contained in any loaded segment > FAIL: shared (non PIC, load offset) > >This one is the only serious error. It's worth investigating why this >is happening. Do other people using PowerPC GNU/Linux see this as >well? dunno, actually only a few PPC/Linux people are using snapshots right now (it is needed to build the egcs mainline). I get this FAIL since early January, 981227 is the last snapshot I have without this problem. What can I do to help to track down this problem? > On the last on the only special thing about shnp.so I noticed is the > following readelf output: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x010000 0x00100000 0x00100000 0x017d0 0x017d0 RWE 0x10000 > DYNAMIC 0x01176c 0x0010176c 0x0010176c 0x00050 0x00050 RW 0x4 > > AFAI remember there are usually 2 LOAD entries here, or? > >Yes, there usually are. However, it is not a requirement. maybe glibc-2.1/glibc-2.1.1pre1 enforce this? Do people on other glibc-2.1 platforms see this failure too? Or is it PPC only? Franz. From kk@ddeorg.soft.net Thu Mar 25 04:01:00 1999 From: kk@ddeorg.soft.net (Koundinya.K) Date: Thu, 25 Mar 1999 04:01:00 -0000 Subject: Problem generating statically linked binaries... Message-ID: <199903251201.RAA06395@bombay.ddeorg.soft.net> Dear Ian and all, I have somehow managed to build the crt* files for my MIPS - R4400 based system running the SVR4.2 UNIX, in order to get the GNU linker working. I am still testing and once I come with something very concrete I will send them to you.. I need to work on those startups for profiling also. O.K In the process I noticed that I am not able to generate statically linked binaries. If I try something like gcc -v -static test.c -o test or gcc -v -Xlinker -Bstatic test.c - test and other combinations .... I get segmenation faults trying to run those binaries. I would like to know , whether the startup files should be modified for building statically linked ones.... I have compiled the startup files using the '-KPIC' option. Even I tried to use the startups that were not compiled with this option , but had no success. Thanks for any pointers to my problem With best regards Koundinya From ian@zembu.com Thu Mar 25 08:40:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Thu, 25 Mar 1999 08:40:00 -0000 Subject: make check problems on powerpc-unknown-linux-gnu References: <99032511382700.00872@ns1102.munich.netsurf.de> Message-ID: <19990325163945.15352.qmail@comton.airs.com> From: Franz Sirl Date: Thu, 25 Mar 1999 11:24:57 +0100 > FAIL: shared (non PIC, load offset) > >This one is the only serious error. It's worth investigating why this >is happening. Do other people using PowerPC GNU/Linux see this as >well? dunno, actually only a few PPC/Linux people are using snapshots right now (it is needed to build the egcs mainline). I get this FAIL since early January, 981227 is the last snapshot I have without this problem. What can I do to help to track down this problem? Whoops, I was confused. I confused that test with others. That test was only added in January 3, so it most likely never worked on PowerPC GNU/Linux. That test uses a special linker script, ld/testsuite/ld-shared/elf-offset.ld That linker script is probably missing something that is in the default PowerPC ELF linker script, ld/scripttempl/elfppc.sc, which is causing the problem. (You can see the default linker script in a slightly more readable form by running ld --verbose). > On the last on the only special thing about shnp.so I noticed is the > following readelf output: > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x010000 0x00100000 0x00100000 0x017d0 0x017d0 RWE 0x10000 > DYNAMIC 0x01176c 0x0010176c 0x0010176c 0x00050 0x00050 RW 0x4 > > AFAI remember there are usually 2 LOAD entries here, or? > >Yes, there usually are. However, it is not a requirement. maybe glibc-2.1/glibc-2.1.1pre1 enforce this? Do people on other glibc-2.1 platforms see this failure too? Or is it PPC only? Actually, there should be PHDR and INTERP entries also; the dynamic linker is probably complaining about the lack of a PHDR entry. Ian From Franz.Sirl-kernel@lauterbach.com Thu Mar 25 18:00:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 25 Mar 1999 18:00:00 -0000 Subject: make check problems on powerpc-unknown-linux-gnu References: <19990325163945.15352.qmail@comton.airs.com> Message-ID: <99032603032500.00625@ns1102.munich.netsurf.de> Am Thu, 25 Mar 1999 schrieb Ian Lance Taylor: >From: Franz Sirl > Date: Thu, 25 Mar 1999 11:24:57 +0100 > > > FAIL: shared (non PIC, load offset) > > > >This one is the only serious error. It's worth investigating why this > >is happening. Do other people using PowerPC GNU/Linux see this as > >well? > > dunno, actually only a few PPC/Linux people are using snapshots right now (it > is needed to build the egcs mainline). I get this FAIL since early January, > 981227 is the last snapshot I have without this problem. What can I do to help > to track down this problem? > >Whoops, I was confused. I confused that test with others. That test >was only added in January 3, so it most likely never worked on PowerPC >GNU/Linux. > >That test uses a special linker script, > ld/testsuite/ld-shared/elf-offset.ld >That linker script is probably missing something that is in the >default PowerPC ELF linker script, ld/scripttempl/elfppc.sc, which is >causing the problem. (You can see the default linker script in a >slightly more readable form by running ld --verbose). That was a good hint :-). This little patch fixes the FAIL for me: --- elf-offset.ld~ Thu Mar 25 19:31:17 1999 +++ elf-offset.ld Thu Mar 25 19:31:43 1999 @@ -1,7 +1,7 @@ SECTIONS { /* Read-only sections, merged into text segment: */ - . = 0x100000; + . = 0x100000 + SIZEOF_HEADERS; .hash : { *(.hash) } .dynsym : { *(.dynsym) } .dynstr : { *(.dynstr) } If this really is only a testsuite bug, I'll take gas-990324 as the standard binutils for an upcoming glibc-2.1 based PPC distribution, cause 2.9.1.0.x seems to corrupt binaries with strip. BTW, what's the planned release date for 2.10? > > On the last on the only special thing about shnp.so I noticed is the > > following readelf output: > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > LOAD 0x010000 0x00100000 0x00100000 0x017d0 0x017d0 RWE 0x10000 > > DYNAMIC 0x01176c 0x0010176c 0x0010176c 0x00050 0x00050 RW 0x4 > > > > AFAI remember there are usually 2 LOAD entries here, or? > > > >Yes, there usually are. However, it is not a requirement. > > maybe glibc-2.1/glibc-2.1.1pre1 enforce this? Do people on other glibc-2.1 > platforms see this failure too? Or is it PPC only? > >Actually, there should be PHDR and INTERP entries also; the dynamic >linker is probably complaining about the lack of a PHDR entry. I noticed a few small differences between the PPC default linker script and the test linker script that might be worth investigating, such as PPC does not sort CONSTRUCTORS, does not incorporate .sdata.* sections and misses some stab.* stuff. Franz. From robertl@sco.com Fri Mar 26 19:32:00 1999 From: robertl@sco.com (Robert Lipe) Date: Fri, 26 Mar 1999 19:32:00 -0000 Subject: dwarf-1 egcs outputs bad .s / GAS allows it. Message-ID: <19990326213126.A3658@rjlhome.sco.com> Two groups copied. Decouple the respective alias from any conversation that doesn't impact that group. I'm not sure, but I think there are two bugs. The first bug is that EGCS emits this. The second is that GAS accepts it. :-) EGCS off the trunk from this morning. GAS is 990223. Both configured for Unixware 7 (i686-pc-sysv5). I have no real reason to believe this is target-specific other that dwarf-1 on x86 isn't a road well travelled. I just analyzed the testsuite failure on bf-pack-1.c. It takes all of '-O3 -fPIC -g' to trigger this bug on this case. /home3/negcs/gcc/xgcc --save-temps -dA -B/home3/negcs/gcc/ /play/egcs/gcc/testsuite/gcc.c-torture/execute/bf-pack-1.c -w -O3 -g -lm -fPIC .L_D8_e: .L_D9: .4byte .L_D9_e-.L_D9 .2byte 0xd / TAG_member .2byte 0x12 / AT_sibling .4byte .L_D10 .2byte 0x38 / AT_name .string "whole" .2byte 0x142 / AT_member .4byte .L_T83 .2byte 0x55 / AT_fund_type .2byte 0xc / FT_unsigned_long .2byte 0xb6 / AT_byte_size .4byte 0x4 .2byte 0xd6 / AT_bit_size .4byte 0x20 .2byte 0xc5 / AT_bit_offset HERE-> .2byte 0xfffffff0 .2byte 0x23 / AT_location .2byte .L_l9_e-.L_l9 .L_l9: .byte 0x4 / OP_CONST .4byte 0x0 This is coming from the end bit_offset_attribute() in dwarfout.c. It calls ASM_OUTPUT_DWARF_DATA2 but bit_offset is negative. ( I don't know why it's negative but when you subtract 0x30 from 0x20 you do indeed get a -0x10.) Should bit_offset be masked to fit in 16 bits? Should it be .4byte? Should this be an impossible combination anyway? Why does GAS allow this? From ian@cygnus.com Sat Mar 27 07:23:00 1999 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 27 Mar 1999 07:23:00 -0000 Subject: dwarf-1 egcs outputs bad .s / GAS allows it. References: <19990326213126.A3658@rjlhome.sco.com> Message-ID: <199903271523.HAA15972@rtl.cygnus.com> Date: Fri, 26 Mar 1999 21:31:26 -0600 From: Robert Lipe HERE-> .2byte 0xfffffff0 Should bit_offset be masked to fit in 16 bits? Should it be .4byte? Should this be an impossible combination anyway? Why does GAS allow this? gas should issue a warning for this case. It doesn't because it needs to accept .2byte -10 and it is getting confused in the obvious way. It's a bug. Ian From donn@interix.com Wed Mar 31 09:22:00 1999 From: donn@interix.com (Donn Terry) Date: Wed, 31 Mar 1999 09:22:00 -0000 Subject: COFF/PE gas regression: bug Message-ID: <370258C3.46EB1F8D@interix.com> Let me quickly introduce myself, and then get on to the topic: I'm Donn Terry, and over the last several years I've been working on the Interix port of the FSF compiler tools (the whole chain, from gcc/egcs thru gdb). I'm now in the process of actively remerging those changes into the official trees, maintainers approving. I'll be working with PE/PEI format stuff, both Intel and Alpha. I've been in contact with Ian and DJ about this. (Yes, I really started with Cygwin stuff.) In the process of doing the Gas port, I've run into something that both the gas2 and bfd lists may wish to discuss, so I'm sending to both (realizing that there may not be much difference between the two.) (And for archive purposes.) I believe the gas testsuite has a bad test, as follows: In testsuite/gas/all/gas.exp, one of the tests is for structure tags (see cofftag*). It creates the symbol _operator as storage class 16 (MOE), type 11 (0xb, MOE). According to the best COFF standard I have (which is no longer on the web that I can find, but was on SCO's website): "A special section number (-2) marks symbolic debugging symbols, including structure/union/enumeration tag names...". (Microsoft's PE documentation agrees, but isn't quite as explicit.) (DJ's machine is not responding at the moment.) The test expects a value of -1 (Absolute symbol), which according to the above is incorrect. I've a fix for this (as part of a larger bundle of fixes), but since it's a visible incompatability, I thought I'd check if anyone cared (either way). (The fix actually affects more than just MOE, obviously, but it follows the standards to the best I can interpret them.) There's more along this line (inconsistencies between the COFF/PE "standards" and the FSF tools); if you in general care about COFF/PE, please respond and I'll collect a "those who care" list about other such items. (DJ, Ian, don't bother; you can't escape :-) !) Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From donn@interix.com Wed Mar 31 09:30:00 1999 From: donn@interix.com (Donn Terry) Date: Wed, 31 Mar 1999 09:30:00 -0000 Subject: Fingers ahead of brain.... Message-ID: <370259B9.2D0BFC9@interix.com> _operator is an enumeration symbol, not a structure member, as my fingers thought :-). Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From ian@airs.com Wed Mar 31 10:24:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Wed, 31 Mar 1999 10:24:00 -0000 Subject: COFF/PE gas regression: bug References: <370258C3.46EB1F8D@interix.com> Message-ID: <19990331182433.20124.qmail@comton.airs.com> Date: Wed, 31 Mar 1999 10:17:55 -0700 From: Donn Terry I believe the gas testsuite has a bad test, as follows: In testsuite/gas/all/gas.exp, one of the tests is for structure tags (see cofftag*). It creates the symbol _operator as storage class 16 (MOE), type 11 (0xb, MOE). According to the best COFF standard I have (which is no longer on the web that I can find, but was on SCO's website): "A special section number (-2) marks symbolic debugging symbols, including structure/union/enumeration tag names...". (Microsoft's PE documentation agrees, but isn't quite as explicit.) (DJ's machine is not responding at the moment.) The test expects a value of -1 (Absolute symbol), which according to the above is incorrect. The best approach for something like this is to see what the tools on some other COFF system do. Can anybody try assembling gas/testsuite/gas/all/cofftag.s on a native COFF system? Ian From jbailey@nisa.net Thu Apr 1 15:02:00 1999 From: jbailey@nisa.net (Jeff Bailey) Date: Thu, 01 Apr 1999 15:02:00 -0000 Subject: gas-990327 snapshot Compile Problem/FIX Message-ID: <19990401150159.A30163@sparky.nisa.net> In libiberty/getruntime.c on an i686-pc-gnu system, the compile fails on line 64 with 'HZ' undefined. To fix, I applied the getruntime.c from the egcs-19990328 snapshot which adds the following lines: #if defined (HAVE_TIMES) && ! defined (HZ) #define HZ CLOCKS_PER_SEC #endif Tks, Jeff Bailey -- The complete lack of evidence is the surest sign that the conspiracy is working. From joel@OARcorp.com Fri Apr 2 06:17:00 1999 From: joel@OARcorp.com (joel@OARcorp.com) Date: Fri, 02 Apr 1999 06:17:00 -0000 Subject: powerpc problems?? Message-ID: Hi, I have reports from one of the RTEMS testers that he is having trouble linking applications with binutils-2.9.1.0.22b for powerpc-rtems (powerpc-eabi) and m68k-rtems (m68k-coff). I am using binutils 2.9.1 and not seeing his problems. Other rtems targets do not show any problems. Other than that, I am using egcs 1.1.2 and he is using the current CVS source off that branch, so I think we are in close sync on that. Are there any known problems that we might have run into here? --joel Joel Sherrill Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From hjl@lucon.org Fri Apr 2 07:09:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 07:09:00 -0000 Subject: powerpc problems?? References: Message-ID: > > > Hi, > > I have reports from one of the RTEMS testers that he is having trouble > linking applications with binutils-2.9.1.0.22b for powerpc-rtems > (powerpc-eabi) and m68k-rtems (m68k-coff). I am using binutils 2.9.1 > and not seeing his problems. Other rtems targets do not show any > problems. > > Other than that, I am using egcs 1.1.2 and he is using the current CVS > source off that branch, so I think we are in close sync on that. > > Are there any known problems that we might have run into here? > Please try binutils 2.9.1.0.23. I fixed a bug which is generic and seems to only affect PPC. -- H.J. Lu (hjl@gnu.org) From borchert@mathematik.uni-ulm.de Fri Apr 2 08:04:00 1999 From: borchert@mathematik.uni-ulm.de (Andreas Borchert) Date: Fri, 02 Apr 1999 08:04:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC Message-ID: <19990402121235.I13794@mathematik.uni-ulm.de> Dear H.J. Lu, gas out of binutils-2.9.1.0.23 (and older versions) has a severe bug for the SPARC platform (sparc-sun-solaris2.6), i.e. it generates wrong code for sethi 0x4000,%i0 (and probably in all other cases where sethi is used without the %hi(...)-construct). The sethi instruction has following suggested assembly syntax (see SPARC Architecture Manual): sethi const22,reg const22 is a 22-bit constant that is placed by sethi in the most significant 22 bits of reg (while it zeroes the 10 least significant bits of reg). Therefore we would expect the value 0x100000 in %i0 after the execution of ``sethi 16384''. Instead of this, gas modifies the given constant such that 0x4000 will be found in %i0 afterwards. This would have been equivalent to sethi %hi(0x4000),%i0 Anyway, I would like to take this opportunity to forward my severe thanks to you. For my compilers gas has always been a life safer. The assembler shipped with Solaris is not just significantly slower, it has much more severe bugs that are not that easy to live with. Kind regards, Andreas Borchert. -- Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm, Germany E-Mail: borchert@mathematik.uni-ulm.de WWW: http://www.mathematik.uni-ulm.de/sai/borchert/ PGP key available via ``finger borchert@laborix.mathematik.uni-ulm.de'' From hjl@lucon.org Fri Apr 2 08:04:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 08:04:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC (fwd) Message-ID: Hi, I can verify that this bug still exists in gas 990330. I am not familiar with Sparc asm. Does anyone have a patch? Thanks. H.J. --- Forwarded message: From hjl@lucon.org Fri Apr 2 11:49:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 11:49:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: <19990402121235.I13794@mathematik.uni-ulm.de> Message-ID: > gas out of binutils-2.9.1.0.23 (and older versions) has a severe bug > for the SPARC platform (sparc-sun-solaris2.6), i.e. it generates > wrong code for > > sethi 0x4000,%i0 > > (and probably in all other cases where sethi is used without the > %hi(...)-construct). > > The sethi instruction has following suggested assembly syntax > (see SPARC Architecture Manual): > > sethi const22,reg > > const22 is a 22-bit constant that is placed by sethi in the most > significant 22 bits of reg (while it zeroes the 10 least significant > bits of reg). Therefore we would expect the value 0x100000 in %i0 > after the execution of ``sethi 16384''. Instead of this, gas > modifies the given constant such that 0x4000 will be found in %i0 > afterwards. This would have been equivalent to > > sethi %hi(0x4000),%i0 > Please try this patch. I know next to nothing about Sparc asm. Please make sure this patch won't break anything on Sparc and let me know the result. I hope someone will make a real fix for this bug. Thanks. H.J. ---- Fri Apr 2 11:44:49 1999 H.J. Lu (hjl@gnu.org) * config/tc-sparc.c (sparc_ip): Fix "sethi const22,reg". Index: tc-sparc.c =================================================================== RCS file: /local/work/cvs/gnu/binutils/gas/config/tc-sparc.c,v retrieving revision 1.10 diff -u -p -r1.10 tc-sparc.c --- tc-sparc.c 1999/03/31 17:24:48 1.10 +++ tc-sparc.c 1999/04/02 19:45:21 @@ -1126,6 +1126,7 @@ sparc_ip (str, pinsn) unsigned int mask = 0; int match = 0; int comma = 0; + int unary = 0; int v9_arg_p; for (s = str; islower ((unsigned char) *s) || (s > str && *s >= '0' && *s <= '8'); ++s) @@ -1876,6 +1877,9 @@ sparc_ip (str, pinsn) }; struct ops *o; + /* We have seen "%xx". */ + unary = 1; + for (o = ops; o->name; o++) if (strncmp (s + 1, o->name, o->len) == 0) break; @@ -1940,6 +1944,21 @@ sparc_ip (str, pinsn) error_message = ": PC-relative operand can't be a constant"; goto error; } + else if (strcmp (insn->name, "sethi") == 0 + && unary == 0) + /* The sethi instruction has following suggested + assembly syntax (see SPARC Architecture Manual): + + sethi const22,reg + + const22 is a 22-bit constant that is placed by + sethi in the most significant 22 bits of reg + (while it zeroes the 10 least significant bits + of reg). It is different from + + sethi %hi(value),reg + */ + the_insn.reloc = BFD_RELOC_SPARC22; /* Constants that won't fit are checked in md_apply_fix3 and bfd_install_relocation. From hjl@lucon.org Fri Apr 2 16:10:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 16:10:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: <19990402121235.I13794@mathematik.uni-ulm.de> Message-ID: > > gas out of binutils-2.9.1.0.23 (and older versions) has a severe bug > for the SPARC platform (sparc-sun-solaris2.6), i.e. it generates > wrong code for > > sethi 0x4000,%i0 > > (and probably in all other cases where sethi is used without the > %hi(...)-construct). > > The sethi instruction has following suggested assembly syntax > (see SPARC Architecture Manual): > > sethi const22,reg > > const22 is a 22-bit constant that is placed by sethi in the most > significant 22 bits of reg (while it zeroes the 10 least significant > bits of reg). Therefore we would expect the value 0x100000 in %i0 > after the execution of ``sethi 16384''. Instead of this, gas > modifies the given constant such that 0x4000 will be found in %i0 > afterwards. This would have been equivalent to > > sethi %hi(0x4000),%i0 > Hi, Here is a new patch. Please discard my last patch to tc-sparc.c. Let me know what you get. Thanks. H.J. --- Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) * sparc-opc.c: Change "sethi" from "h,d" to "n,d". Index: ChangeLog.linux =================================================================== RCS file: /local/work/cvs/gnu/binutils/opcodes/ChangeLog.linux,v retrieving revision 1.40 diff -u -p -r1.40 ChangeLog.linux --- ChangeLog.linux 1999/03/31 17:24:49 1.40 +++ ChangeLog.linux 1999/04/03 00:05:33 @@ -1,3 +1,5 @@ +Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) + Sun Mar 28 11:48:17 1999 H.J. Lu (hjl@gnu.org) * i386-dis.c (INSN_FWAIT): New, defined. Index: sparc-opc.c =================================================================== RCS file: /local/work/cvs/gnu/binutils/opcodes/sparc-opc.c,v retrieving revision 1.7 diff -u -p -r1.7 sparc-opc.c --- sparc-opc.c 1998/12/05 03:38:56 1.7 +++ sparc-opc.c 1999/04/03 00:00:22 @@ -1379,7 +1379,7 @@ CONDFC ("fbule", "cb013", 0xe, 0), { "setsw", F2(0x0, 0x4), F2(~0x0, ~0x4), "Sh,d", F_ALIAS, v9 }, { "setx", F2(0x0, 0x4), F2(~0x0, ~0x4), "S0,1,d", F_ALIAS, v9 }, -{ "sethi", F2(0x0, 0x4), F2(~0x0, ~0x4), "h,d", 0, v6 }, +{ "sethi", F2(0x0, 0x4), F2(~0x0, ~0x4), "n,d", 0, v6 }, { "taddcc", F3(2, 0x20, 0), F3(~2, ~0x20, ~0)|ASI(~0), "1,2,d", 0, v6 }, { "taddcc", F3(2, 0x20, 1), F3(~2, ~0x20, ~1), "1,i,d", 0, v6 }, From ian@airs.com Fri Apr 2 16:42:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Fri, 02 Apr 1999 16:42:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: Message-ID: <19990403004249.1582.qmail@comton.airs.com> From: hjl@lucon.org (H.J. Lu) Date: Fri, 2 Apr 1999 16:41:52 -0800 (PST) You are right. That shows I know nothing about Sparc. Do you have a fix for the bug? No, I haven't had a chance to look into it yet. I know I am behind. I'll try to catch up soon. Ian From hjl@lucon.org Fri Apr 2 16:42:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 16:42:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: <19990403003707.1536.qmail@comton.airs.com> Message-ID: > > From: hjl@lucon.org (H.J. Lu) > Date: Fri, 2 Apr 1999 16:10:48 -0800 (PST) > > > gas out of binutils-2.9.1.0.23 (and older versions) has a severe bug > > for the SPARC platform (sparc-sun-solaris2.6), i.e. it generates > > wrong code for > > > > sethi 0x4000,%i0 > > > > (and probably in all other cases where sethi is used without the > > %hi(...)-construct). > > > > The sethi instruction has following suggested assembly syntax > > (see SPARC Architecture Manual): > > > > sethi const22,reg > > > > const22 is a 22-bit constant that is placed by sethi in the most > > significant 22 bits of reg (while it zeroes the 10 least significant > > bits of reg). Therefore we would expect the value 0x100000 in %i0 > > after the execution of ``sethi 16384''. Instead of this, gas > > modifies the given constant such that 0x4000 will be found in %i0 > > afterwards. This would have been equivalent to > > > > sethi %hi(0x4000),%i0 > > Here is a new patch. Please discard my last patch to tc-sparc.c. > Let me know what you get. > > Thanks. > > > H.J. > --- > Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) > > * sparc-opc.c: Change "sethi" from "h,d" to "n,d". > > I don't think that can be right. I think it will do the wrong thing > for > sethi foo,%i0 > You are right. That shows I know nothing about Sparc. Do you have a fix for the bug? Thanks. -- H.J. Lu (hjl@gnu.org) From ian@airs.com Fri Apr 2 16:42:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Fri, 02 Apr 1999 16:42:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: Message-ID: <19990403003707.1536.qmail@comton.airs.com> From: hjl@lucon.org (H.J. Lu) Date: Fri, 2 Apr 1999 16:10:48 -0800 (PST) > gas out of binutils-2.9.1.0.23 (and older versions) has a severe bug > for the SPARC platform (sparc-sun-solaris2.6), i.e. it generates > wrong code for > > sethi 0x4000,%i0 > > (and probably in all other cases where sethi is used without the > %hi(...)-construct). > > The sethi instruction has following suggested assembly syntax > (see SPARC Architecture Manual): > > sethi const22,reg > > const22 is a 22-bit constant that is placed by sethi in the most > significant 22 bits of reg (while it zeroes the 10 least significant > bits of reg). Therefore we would expect the value 0x100000 in %i0 > after the execution of ``sethi 16384''. Instead of this, gas > modifies the given constant such that 0x4000 will be found in %i0 > afterwards. This would have been equivalent to > > sethi %hi(0x4000),%i0 Here is a new patch. Please discard my last patch to tc-sparc.c. Let me know what you get. Thanks. H.J. --- Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) * sparc-opc.c: Change "sethi" from "h,d" to "n,d". I don't think that can be right. I think it will do the wrong thing for sethi foo,%i0 Ian From hjl@lucon.org Fri Apr 2 17:27:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 02 Apr 1999 17:27:00 -0000 Subject: Bug of gas (binutils-2.9.1.0.23): Wrong code for SETHI on SPARC References: <19990403003707.1536.qmail@comton.airs.com> Message-ID: > Let me know what you get. > > Thanks. > > > H.J. > --- > Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) > > * sparc-opc.c: Change "sethi" from "h,d" to "n,d". > > I don't think that can be right. I think it will do the wrong thing > for > sethi foo,%i0 > First, the current gas handles sethi foo,%i0 differently than Solaris' as. Solaris' as generates R_SPARC_22. But gas generates R_SPARC_HI22. The patch enclosed here makes gas matches Solaris' as. But I don't know if it is correct :-). Thanks. -- H.J. Lu (hjl@gnu.org) --- Index: gas/ChangeLog.linux =================================================================== RCS file: /local/work/cvs/gnu/binutils/gas/ChangeLog.linux,v retrieving revision 1.62 diff -u -p -r1.62 ChangeLog.linux --- gas/ChangeLog.linux 1999/03/31 18:21:59 1.62 +++ gas/ChangeLog.linux 1999/04/03 01:22:45 @@ -1,3 +1,7 @@ +Fri Apr 2 17:22:33 1999 H.J. Lu (hjl@gnu.org) + + * config/tc-sparc.c (tc_gen_reloc): Handle BFD_RELOC_SPARC22. + Sun Mar 28 15:32:42 1999 H.J. Lu (hjl@gnu.org) * Makefile.in: Regenerated with automake 1.4. Index: gas/config/tc-sparc.c =================================================================== RCS file: /local/work/cvs/gnu/binutils/gas/config/tc-sparc.c,v retrieving revision 1.10 diff -u -p -r1.10 tc-sparc.c --- gas/config/tc-sparc.c 1999/03/31 17:24:48 1.10 +++ gas/config/tc-sparc.c 1999/04/03 01:05:44 @@ -2721,6 +2721,7 @@ tc_gen_reloc (section, fixp) case BFD_RELOC_LO10: case BFD_RELOC_32_PCREL_S2: case BFD_RELOC_SPARC13: + case BFD_RELOC_SPARC22: case BFD_RELOC_SPARC_BASE13: case BFD_RELOC_SPARC_WDISP16: case BFD_RELOC_SPARC_WDISP19: Index: opcodes/ChangeLog.linux =================================================================== RCS file: /local/work/cvs/gnu/binutils/opcodes/ChangeLog.linux,v retrieving revision 1.40 diff -u -p -r1.40 ChangeLog.linux --- opcodes/ChangeLog.linux 1999/03/31 17:24:49 1.40 +++ opcodes/ChangeLog.linux 1999/04/03 01:07:01 @@ -1,3 +1,7 @@ +Fri Apr 2 16:05:25 1999 H.J. Lu (hjl@gnu.org) + + * sparc-opc.c: Change "sethi" from "h,d" to "n,d". + Sun Mar 28 11:48:17 1999 H.J. Lu (hjl@gnu.org) * i386-dis.c (INSN_FWAIT): New, defined. Index: opcodes/sparc-opc.c =================================================================== RCS file: /local/work/cvs/gnu/binutils/opcodes/sparc-opc.c,v retrieving revision 1.7 diff -u -p -r1.7 sparc-opc.c --- opcodes/sparc-opc.c 1998/12/05 03:38:56 1.7 +++ opcodes/sparc-opc.c 1999/04/03 01:06:34 @@ -1379,7 +1379,7 @@ CONDFC ("fbule", "cb013", 0xe, 0), { "setsw", F2(0x0, 0x4), F2(~0x0, ~0x4), "Sh,d", F_ALIAS, v9 }, { "setx", F2(0x0, 0x4), F2(~0x0, ~0x4), "S0,1,d", F_ALIAS, v9 }, -{ "sethi", F2(0x0, 0x4), F2(~0x0, ~0x4), "h,d", 0, v6 }, +{ "sethi", F2(0x0, 0x4), F2(~0x0, ~0x4), "n,d", 0, v6 }, { "taddcc", F3(2, 0x20, 0), F3(~2, ~0x20, ~0)|ASI(~0), "1,2,d", 0, v6 }, { "taddcc", F3(2, 0x20, 1), F3(~2, ~0x20, ~1), "1,i,d", 0, v6 }, From leisner@rochester.rr.com Sun Apr 4 21:48:00 1999 From: leisner@rochester.rr.com (Marty Leisner) Date: Sun, 04 Apr 1999 21:48:00 -0000 Subject: should this configure line work? Message-ID: <199904050448.AAA25026@rochester.rr.com> I'm working again with gas alphas... Should this line work (I copied it from a released 2.9): 296 /usr/local/src/gnu/gas-990403/configure --prefix=/usr/gnu/gas-990403 --enable-commonbfdlib --enable-shared --enable-targets=i386-go32,i386-bsd,i386-pe I end up getting: gcc -g -O2 -o .libs/ld-new ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o eelf_i386.o ei386linux.o ei386go32.o ei386bsd.o ei386pe.o -Wl,--rpath -Wl,/usr/gnu/gas-990403/lib ../bfd/.libs/libbfd.so ../libiberty/libiberty.a ei386pe.o: In function `gld_i386pe_parse_args': /usr/local/obj/gas-990403/ld/ei386pe.c:414: undefined reference to `pe_dll_export_everything' /usr/local/obj/gas-990403/ld/ei386pe.c:418: undefined reference to `pe_dll_add_excludes' /usr/local/obj/gas-990403/ld/ei386pe.c:422: undefined reference to `pe_dll_kill_ats' /usr/local/obj/gas-990403/ld/ei386pe.c:425: undefined reference to `pe_dll_stdcall_aliases' ei386pe.o: In function `gld_i386pe_after_open': /usr/local/obj/gas-990403/ld/ei386pe.c:621: undefined reference to `pe_process_import_defs' /usr/local/obj/gas-990403/ld/ei386pe.c:623: undefined reference to `pe_dll_build_sections' ei386pe.o: In function `gld_i386pe_unrecognized_file': /usr/local/obj/gas-990403/ld/ei386pe.c:706: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:707: undefined reference to `def_file_empty' /usr/local/obj/gas-990403/ld/ei386pe.c:707: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:708: undefined reference to `def_file_parse' /usr/local/obj/gas-990403/ld/ei386pe.c:709: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:720: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:720: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:738: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:760: undefined reference to `pe_def_file' ei386pe.o:/usr/local/obj/gas-990403/ld/ei386pe.c:763: more undefined references to `pe_def_file' follow ei386pe.o: In function `gld_i386pe_recognized_file': /usr/local/obj/gas-990403/ld/ei386pe.c:791: undefined reference to `pe_implied_import_dll' ei386pe.o: In function `gld_i386pe_finish': /usr/local/obj/gas-990403/ld/ei386pe.c:803: undefined reference to `pe_dll_fill_sections' /usr/local/obj/gas-990403/ld/ei386pe.c:805: undefined reference to `pe_def_file' /usr/local/obj/gas-990403/ld/ei386pe.c:805: undefined reference to `pe_dll_generate_implib' /usr/local/obj/gas-990403/ld/ei386pe.c:808: undefined reference to `pe_dll_generate_def_file' collect2: ld returned 1 exit status make[3]: *** [ld-new] Error 1 make[3]: Leaving directory `/usr/local/obj/gas-990403/ld' (this was a probably with gas from a month ago). (can someone change my address from leisner@sdsp.mc.xerox.com to leisner@rochester.rr.com on this list...I didn't see any instructions). Marty Leisner leisner@rochester.rr.com From bothner@cygnus.com Sun Apr 4 22:57:00 1999 From: bothner@cygnus.com (Per Bothner) Date: Sun, 04 Apr 1999 22:57:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: Message-ID: <199904050553.WAA18389@cygnus.com> > I don't think I am prepared to hack up > config.guess to cater for this, unless someone has a more elegant > solution. Alternatives: * Give full path of ld: /usr/bin/ld. * Cd to some directory unlikely to contain ld: (cd /; ld) --Per Bothner Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner From bje@cygnus.com Sun Apr 4 23:02:00 1999 From: bje@cygnus.com (Ben Elliston) Date: Sun, 04 Apr 1999 23:02:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: <199904050553.WAA18389@cygnus.com> Message-ID: > Alternatives: > * Give full path of ld: /usr/bin/ld. This is almost certainly guaranteed to fail on 50% of the systems I have ever used. I think hardcoding the location of `ld' is a bad idea. > * Cd to some directory unlikely to contain ld: (cd /; ld) This idea, on the other hand, shows promise. Since the script can run `ld' from anywhere, perhaps all this needs in addition is something like: (here=`pwd`; cd /; ld; cd $here) (to restore the original working directory afterwards). Thanks, Per. I'll look into this. Ben From bothner@cygnus.com Sun Apr 4 23:25:00 1999 From: bothner@cygnus.com (Per Bothner) Date: Sun, 04 Apr 1999 23:25:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: Message-ID: <199904050625.XAA18984@cygnus.com> >> * Give full path of ld: /usr/bin/ld. > This is almost certainly guaranteed to fail on 50% of the systems I have > ever used. That is irrelevant. The question is: Is it likely to fail on *Linux* systems, since (as far as I can tell) those are the only ones that will be running ld? > (here=`pwd`; cd /; ld; cd $here) > (to restore the original working directory afterwards). Thanks, Per. Or just do: (cd /; ld) Remember: (CMD) runs CMD in a sub-shell. --Per Bothner Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner From bje@cygnus.com Sun Apr 4 23:33:00 1999 From: bje@cygnus.com (Ben Elliston) Date: Sun, 04 Apr 1999 23:33:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: <199904050625.XAA18984@cygnus.com> Message-ID: > That is irrelevant. The question is: Is it likely to fail on > *Linux* systems, since (as far as I can tell) those are the only > ones that will be running ld? True; although, for instance, my ld is not in /usr/bin. My ld is in /usr/local/bin, and /usr/bin/ld will report the wrong executable format. The point I was trying to make is that the script should be using the PATH to pick up the user's choice of tools in as many circumstances as possible. > Or just do: > (cd /; ld) > Remember: (CMD) runs CMD in a sub-shell. Silly me. Thanks, Ben From bje@cygnus.com Mon Apr 5 03:26:00 1999 From: bje@cygnus.com (Ben Elliston) Date: Mon, 05 Apr 1999 03:26:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: <199904050553.WAA18389@cygnus.com> Message-ID: > * Cd to some directory unlikely to contain ld: (cd /; ld) Here is a patch which seems to work fine. Does anyone see any potential problems with this? *** config.guess 1999/03/21 14:01:53 1.138 --- config.guess 1999/04/05 10:17:18 *************** *** 608,614 **** # The BFD linker knows what the default object file format is, so # first see if it will tell us. ! ld_help_string=`ld --help 2>&1` ld_supported_emulations=`echo $ld_help_string \ | sed -ne '/supported emulations:/!d s/[ ][ ]*/ /g --- 608,614 ---- # The BFD linker knows what the default object file format is, so # first see if it will tell us. ! pwd=`pwd`; cd /; ld_help_string=`ld --help 2>&1`; cd $pwd ld_supported_emulations=`echo $ld_help_string \ | sed -ne '/supported emulations:/!d s/[ ][ ]*/ /g From joel@OARcorp.com Mon Apr 5 06:43:00 1999 From: joel@OARcorp.com (joel@OARcorp.com) Date: Mon, 05 Apr 1999 06:43:00 -0000 Subject: binutils powerpc problems (fwd) Message-ID: Bummer... upgrading did not solve this one for Ralf. :( Here is what he sent me. --joel ---------- Forwarded message ---------- Date: Sat, 03 Apr 1999 05:40:41 +0200 From: Ralf Corsepius To: joel@oarcorp.com Subject: Re: binutils powerpc problems joel@oarcorp.com wrote: > I know Ralf ran into this. Just in case someone else did, here is the > response. Let me know if this fixes it for you. No, it doesn't. The situation is the same with binutils-2.9.1.0.22b, binutils-2.9.1.0.23 and gas-990324 But now I think I've found the problem: /usr/bin/install -c -m 0644 ../../../../../../../../rtems-rc-19990401-0/c/src/lib/libbsp/powerpc/dmv177/wrapup/../bsp_specs /lfs/poseidon/users/rtems/src/multi/build/./eth_comm/lib/bsp_specs ==>The wrong bsp_specs file gets installed to the build-tree. This happens during processing the preinstall rule in c/Makefile. This is an excerpt of: c/make_src_makefiles > [..] > ./src/lib/libbsp/shmdr/Makefile > ./src/lib/libbsp/powerpc/dmv177/wrapup/Makefile > ./src/lib/libbsp/powerpc/eth_comm/wrapup/Makefile > ./src/lib/libbsp/powerpc/helas403/wrapup/Makefile > ./src/lib/libbsp/powerpc/papyrus/wrapup/Makefile > ./src/lib/libbsp/powerpc/ppcn_60x/wrapup/Makefile > ./src/lib/libbsp/powerpc/psim/wrapup/Makefile > ./src/lib/libbsp/powerpc/score603e/wrapup/Makefile > ./src/lib/libc/Makefile > [..] > Each of these lines is read in and the Makefile contained in this line is called with RTEMS_BSP=${RTEMS_BSP} passed through the environment. Each of the wrapup/Makefile's contains a rule of this kind: > $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs: ../bsp_specs > $(INSTALL_DATA) $< $@ > > preinstall: $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs > With "make RTEMS_BSP=eth_comm" invoked in src/lib/libbsp/powerpc/dmv177, the dmv177 bsp_specs gets installed for eth_comm and no other bsp_specs will get installed afterwards. That preinstall crap interfers with one of my "towards automake" patches again ------ This would also explain why I am not able to build most of the m68k BSPs (Not yet cross-checked) ------ Now I don't understand why you don't seem to be effected by this problem. AFAIS, it must be present for all cpus with more than one BSP ! I assume the cause for you not getting this problem is the order of inodes on our disks, because c/Makefile.in applies "find", which by lucky chance installs a bsp_specs to the build-tree which presumably is compatible to all powerpc BSPs in your case and only to some BSPs in my case. ------ I don't have a work-around or fix for this problem yet (It's 5:30am and I urgently need to get some sleep), but this bug is severe enough to be fixed pretty soon, if not to release a new snapshot. I can imagine half a dozen of find/sed/grep/make trickery to work around this problem in c/Makefile.in, so I can probably come up with a work-around tomorrow, however I didn't find anything convincing yet. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999 http://www.faw.uni-ulm.de From meyering@ascend.com Mon Apr 5 06:46:00 1999 From: meyering@ascend.com (Jim Meyering) Date: Mon, 05 Apr 1999 06:46:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: Message-ID: <87lng76vhm.fsf@ascend.com> Ben Elliston writes: | > * Cd to some directory unlikely to contain ld: (cd /; ld) | | Here is a patch which seems to work fine. Does anyone see any potential | problems with this? | | *** config.guess 1999/03/21 14:01:53 1.138 | --- config.guess 1999/04/05 10:17:18 | *************** | *** 608,614 **** | | # The BFD linker knows what the default object file format is, so | # first see if it will tell us. | ! ld_help_string=`ld --help 2>&1` | ld_supported_emulations=`echo $ld_help_string \ | | sed -ne '/supported emulations:/!d | s/[ ][ ]*/ /g | --- 608,614 ---- | | # The BFD linker knows what the default object file format is, so | # first see if it will tell us. | ! pwd=`pwd`; cd /; ld_help_string=`ld --help 2>&1`; cd $pwd | ld_supported_emulations=`echo $ld_help_string \ | | sed -ne '/supported emulations:/!d | s/[ ][ ]*/ /g That will not change back to the proper directory if pwd fails. It's more robust to do the cd from a subshell instead -- then you don't have to be able to return to the working directory: ld_help_string=`cd /; ld --help 2>&1` Also, I think the `cd /' part deserves a comment. From hjl@lucon.org Mon Apr 5 08:10:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Mon, 05 Apr 1999 08:10:00 -0000 Subject: binutils powerpc problems (fwd) References: Message-ID: > > > > Bummer... upgrading did not solve this one for Ralf. :( > > Here is what he sent me. > > --joel > > > ---------- Forwarded message ---------- > Date: Sat, 03 Apr 1999 05:40:41 +0200 > From: Ralf Corsepius > To: joel@oarcorp.com > Subject: Re: binutils powerpc problems > > joel@oarcorp.com wrote: > > > I know Ralf ran into this. Just in case someone else did, here is the > > response. Let me know if this fixes it for you. > > No, it doesn't. > > The situation is the same with binutils-2.9.1.0.22b, binutils-2.9.1.0.23 > and gas-990324 > > But now I think I've found the problem: > > /usr/bin/install -c -m 0644 > ../../../../../../../../rtems-rc-19990401-0/c/src/lib/libbsp/powerpc/dmv177/wrapup/../bsp_specs > /lfs/poseidon/users/rtems/src/multi/build/./eth_comm/lib/bsp_specs > > ==>The wrong bsp_specs file gets installed to the build-tree. > > This happens during processing the preinstall rule in c/Makefile. > > This is an excerpt of: c/make_src_makefiles > > > [..] > > ./src/lib/libbsp/shmdr/Makefile > > ./src/lib/libbsp/powerpc/dmv177/wrapup/Makefile > > ./src/lib/libbsp/powerpc/eth_comm/wrapup/Makefile > > ./src/lib/libbsp/powerpc/helas403/wrapup/Makefile > > ./src/lib/libbsp/powerpc/papyrus/wrapup/Makefile > > ./src/lib/libbsp/powerpc/ppcn_60x/wrapup/Makefile > > ./src/lib/libbsp/powerpc/psim/wrapup/Makefile > > ./src/lib/libbsp/powerpc/score603e/wrapup/Makefile > > ./src/lib/libc/Makefile > > [..] > > > Each of these lines is read in and the Makefile contained in this line is > called with RTEMS_BSP=${RTEMS_BSP} passed through the environment. > > Each of the wrapup/Makefile's contains a rule of this kind: > > > $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs: ../bsp_specs > > $(INSTALL_DATA) $< $@ > > > > preinstall: $(PROJECT_ROOT)/${RTEMS_BSP}/bsp_specs > > > > With "make RTEMS_BSP=eth_comm" invoked in src/lib/libbsp/powerpc/dmv177, > the dmv177 bsp_specs gets installed for eth_comm and no other bsp_specs > will get installed afterwards. > > That preinstall crap interfers with one of my "towards automake" > patches again > > ------ > This would also explain why I am not able to build most of the m68k BSPs > (Not yet cross-checked) > > ------ > Now I don't understand why you don't seem to be effected by this problem. > AFAIS, it must be present for all cpus with more than one BSP ! > > I assume the cause for you not getting this problem is the order of inodes > on our disks, because c/Makefile.in applies "find", which by lucky chance > installs a bsp_specs to the build-tree which presumably is compatible to > all powerpc BSPs in your case and only to some BSPs in my case. > > ------ > I don't have a work-around or fix for this problem yet (It's 5:30am and I > urgently need to get some sleep), but this bug is severe enough to be fixed > pretty soon, if not to release a new snapshot. > > I can imagine half a dozen of find/sed/grep/make trickery to work around > this problem in c/Makefile.in, so I can probably come up with a work-around > tomorrow, however I didn't find anything convincing yet. > > Ralf > > I added --multilib-dir PATH Specify a target directory to ld to solve the similar problem of one of my clients. They have more one one BSP for one CPU. If you use binutils 2.9.1.0.2x, it is in there. Here is the whole ChangeLog: Wed Sep 16 07:32:44 1998 H.J. Lu (hjl@gnu.org) * ld.h (args_type): Add one field, multilib_dir. * ldfile.c (ldfile_add_library_path): Add one argument, append. * ldfile.h (ldfile_add_library_path): Likewise. * ldgram.y: Calling ldfile_add_library_path with one more argument, true. * ldmain.c: Likewise. * lexsup.c: Likewise. * ldmain.c (check_for_scripts_dir): Add one argument, append. (main): Initialize command_line.multilib_dir to NULL. (set_scripts_dir): If command_line.multilib_dir is not NULL, prepend it to search path. * lexsup.c (OPTION_MULTILIB_DIR): New. (parse_args): Handle OPTION_MULTILIB_DIR. * emultempl/elf32.em (gld${EMULATION_NAME}_get_script): If command_line.multilib_dir != NULL, get linker scripts from files. It may be useful to solve your problem. -- H.J. Lu (hjl@gnu.org) From carlo@runaway.xs4all.nl Mon Apr 5 08:17:00 1999 From: carlo@runaway.xs4all.nl (Carlo Wood) Date: Mon, 05 Apr 1999 08:17:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: Message-ID: <199904051358.PAA02063@jolan.ppro> | > Or just do: | > (cd /; ld) | > Remember: (CMD) runs CMD in a sub-shell. | | Silly me. Thanks, | | Ben I'd suggest to do that where you detect the path to ld: ld_exec=`(cd /; which ld)` After all, the problem is in `which', not in the normal shell search. [ proof: ~/tmp>ls -ld ld drwxr-xr-x 2 carlo users 1024 Apr 5 15:55 ld/ ~/tmp>ld -V GNU ld version 2.9.1 (with BFD 2.9.1.0.15) Supported emulations: elf_i386 i386linux ] I already mailed to Ben, I intend to rewrite `which' so it behaves the same as the shell search (ie, will skip directories). I suppose that if (!access(test, X_OK) && !stat(test, &m)) found = S_ISREG(m.st_mode); will do? [ Now it just does the access(test, X_OK) ]. I suppose the main problem will be to get everyone to upgrade their `which' ;). -- Carlo Wood PS dkl@redhat.com : reference, bug #1998 From donn@interix.com Mon Apr 5 08:31:00 1999 From: donn@interix.com (Donn Terry) Date: Mon, 05 Apr 1999 08:31:00 -0000 Subject: COFF/PE gas regression: bug References: <19990331182433.20124.qmail@comton.airs.com> Message-ID: <3708D661.36E95338@interix.com> Given the enthusiastic(?) response over the last most-of-a-week, I think it's reasonable to conclude that there isn't much interest left in "ordinary" COFF. (I won't go so far as "none", because I'm sure there are interested folks who aren't on this list.) I'm not sure whether that makes things harder or easier; the lack of a comparison base will definitely make things harder. (I have someone within Softway who thinks they may be able to come up with something, but until it happens, it hasn't happened :-) ). Donn Ian Lance Taylor wrote: > > Date: Wed, 31 Mar 1999 10:17:55 -0700 > From: Donn Terry > > I believe the gas testsuite has a bad test, as follows: In > testsuite/gas/all/gas.exp, one of the tests is for structure tags > (see cofftag*). It creates the symbol _operator as > storage class 16 (MOE), type 11 (0xb, MOE). According to > the best COFF standard I have (which is no longer on > the web that I can find, but was on SCO's website): > "A special section number (-2) marks symbolic debugging symbols, > including structure/union/enumeration tag names...". > (Microsoft's PE documentation agrees, but isn't quite as > explicit.) (DJ's machine is not responding at the moment.) > > The test expects a value of -1 (Absolute symbol), which according > to the above is incorrect. > > The best approach for something like this is to see what the tools on > some other COFF system do. Can anybody try assembling > gas/testsuite/gas/all/cofftag.s on a native COFF system? > > Ian -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From phdm@macqel.be Mon Apr 5 16:39:00 1999 From: phdm@macqel.be (Philippe De Muyter) Date: Mon, 05 Apr 1999 16:39:00 -0000 Subject: COFF/PE gas regression: bug References: <3708D661.36E95338@interix.com> Message-ID: <199904052322.BAA16372@mail.macqel.be> > > Can anybody try assembling > > gas/testsuite/gas/all/cofftag.s on a native COFF system? Here it is (on m68k-motorola-sysv). I have regenerated cofftag.s with my native compiler, because my native assembler refused to assemble cofftag.s from the testsuite. ---------------------------- cofftag.s ----------------------------------- file "cofftag.c" data 1 global token token: short 0x0000 text def token; scl 15; type 012; size 4; endef def operator; val 0; scl 16; type 013; endef def flags; val 1; scl 16; type 013; endef def ~eos; val 4; scl 102; tag token; size 4; endef data 1 even global what what: long 0 -------------------------------------------------------------------------- and here are the result of the native `nm' and of objdump --syms phdm/mac_tst nm cofftag.o Symbols from cofftag.o: Name Value Class Type Size Line Section cofftag.c | | file | | | | token | |entag | enum| 4| | operator | 0|enmem | enmem| | |(ABS) flags | 1|enmem | enmem| | |(ABS) .eos | |endstr| null| 4| |(ABS) token | 0|extern| null| | |.data what | 2|extern| null| | |.data phdm/mac_tst objdump --syms -a cofftag.o cofftag.o: file format coff-m68k cofftag.o SYMBOL TABLE: [ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x00000000 cofftag.c File [ 2](sec -2)(fl 0x00)(ty a)(scl 15) (nx 1) 0x00000000 token AUX lnno 0 size 0x4 tagndx 0 endndx 8 [ 4](sec -1)(fl 0x00)(ty b)(scl 16) (nx 0) 0x00000000 operator [ 5](sec -1)(fl 0x00)(ty b)(scl 16) (nx 0) 0x00000001 flags [ 6](sec -1)(fl 0x00)(ty 0)(scl 102) (nx 1) 0x00000004 .eos AUX lnno 0 size 0x4 tagndx 2 [ 8](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text AUX scnlen 0x0 nreloc 0 nlnno 0 [ 10](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .data AUX scnlen 0x8 nreloc 0 nlnno 0 [ 12](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000008 .bss AUX scnlen 0x0 nreloc 0 nlnno 0 [ 14](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 token [ 15](sec 2)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000002 what The section number used is -1, not -2. I still hope this helps. Philippe From rms@gnu.org Tue Apr 6 02:20:00 1999 From: rms@gnu.org (Richard Stallman) Date: Tue, 06 Apr 1999 02:20:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: Message-ID: <199904060920.FAA10325@psilocin.gnu.org> > That is irrelevant. The question is: Is it likely to fail on > *Linux* systems, since (as far as I can tell) those are the only > ones that will be running ld? Please keep in mind that Linux is the kernel; the system in which Linux is typically used is basically a modified version of the GNU system. Please help the GNU Project by calling the system GNU/Linux. While I know this won't help solve the particular bug at hand, it is very important for the GNU Project. See http://www.gnu.org/gnu/linux-and-gnu.html for more explanation. In this case, the issue probably has nothing to do with the kernel per se. It is an issue of the GNU system. Thank you in advance. From donn@interix.com Tue Apr 6 07:55:00 1999 From: donn@interix.com (Donn Terry) Date: Tue, 06 Apr 1999 07:55:00 -0000 Subject: COFF/PE gas regression: bug References: <199904052322.BAA16372@mail.macqel.be> Message-ID: <370A1F56.3DD2541F@interix.com> Thanks. Interesting... I suspect that that explains why the current gas is the way it is; whether that's right or not I'm not sure yet. (Clearly, according to the documentation it's wrong.) I'd like to see the results from a System V i386 COFF system so we can determine if it's the documentation or the Motorola code that's wrong. (I suspect we'll need some sort of conditional to resolve this one, but we'll see.) Donn =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From ian@zembu.com Tue Apr 6 08:11:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Tue, 06 Apr 1999 08:11:00 -0000 Subject: COFF/PE gas regression: bug References: <370A1F56.3DD2541F@interix.com> Message-ID: <19990406151131.15260.qmail@comton.airs.com> Date: Tue, 06 Apr 1999 08:51:02 -0600 From: Donn Terry Interesting... I suspect that that explains why the current gas is the way it is; whether that's right or not I'm not sure yet. (Clearly, according to the documentation it's wrong.) I'd like to see the results from a System V i386 COFF system so we can determine if it's the documentation or the Motorola code that's wrong. The SVR3 implementations are pretty much all the same, since the came from a common code base. I'd be very surprised if they differed. COFF documentation was always completely inadequate. Don't be surprised if you see other problems like this. Moreover, I was moved to check the O'Reilly book on COFF. It says that C_MOS, C_MOU and C_MOE symbols are N_ABS. Here is the table from the book (table 8-1, p. 100): C_EXT N_ABS, N_UNDEF, N_SCNUM C_AUTO N_ABS C_REG N_ABS C_LABEL N_UNDEF, N_SCNUM C_MOS N_ABS C_ARG N_ABS C_STRTAG N_DEBUG C_MOU N_ABS C_UNTAG N_DEBUG C_TPDEF N_DEBUG C_ENTAG N_DEBUG C_MOE N_ABS C_REGPARM N_ABS C_FIELD N_ABS C_BLOCK N_SCNUM C_FCN N_SCNUM C_EOS N_ABS C_FILE N_DEBUG According to this book, N_DEBUG is for ``a special symbolic debugging symbol (an assembler symbolic directive)'' and N_ABS is for ``an absolute value.'' It expands on that by saying that N_DEBUG ``in general means that the value has no meaning.'' (I suspect we'll need some sort of conditional to resolve this one, but we'll see.) Why does it matter? My understanding is that Microsoft doesn't use that sort of debugging information, so what program actually cares? Ian From donn@interix.com Tue Apr 6 08:20:00 1999 From: donn@interix.com (Donn Terry) Date: Tue, 06 Apr 1999 08:20:00 -0000 Subject: COFF/PE gas regression: bug References: <19990406151131.15260.qmail@comton.airs.com> Message-ID: <370A2533.73DA217@interix.com> > Why does it matter? My understanding is that Microsoft doesn't use > that sort of debugging information, so what program actually cares? I don't remember *yet*. I made a lot of these changes quite some time ago, and I suspect I ran across something that forced me to look at it more deeply. I'll hold the patch until I can make the case for it (which may be never.) Consider the topic dropped for now. Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From carlo@runaway.xs4all.nl Tue Apr 6 09:21:00 1999 From: carlo@runaway.xs4all.nl (Carlo Wood) Date: Tue, 06 Apr 1999 09:21:00 -0000 Subject: [cygnus.gas2] binutils bug: config.guess References: <199904060920.FAA10325@psilocin.gnu.org> Message-ID: <199904061455.QAA07552@jolan.ppro> Richard Stallman wrote: | In this case, the issue probably has nothing to do with the kernel per | se. It is an issue of the GNU system. I'd like to repeat that the problem is in `which', I recall that in binutils I saw `which' being used to determine the path to `ld', which was the problem. I rewrote `which' and called it which-2.0.tar.gz This is a more mature version ;), and I'd welcome it if it could become a (the) standard GNU utility, although it won't work likely on other architectures than GNU/Linux yet. I uploaded it to metalab and announced it to comp.os.linux.announce I am in the process to get it added to RedHat 6.0 and I suppose that will succeed. Home page: http://www.xs4all.nl/~carlo17/which/ -- Carlo Wood From jquinn@nortelnetworks.com Tue Apr 6 10:42:00 1999 From: jquinn@nortelnetworks.com (Jerry Quinn) Date: Tue, 06 Apr 1999 10:42:00 -0000 Subject: PATCH: pa2.0 float instructions Message-ID: <370A4029.432AE419@americasm01.nt.com> Hi, all. The attached patch is against the 990329 gas snapshot. It does two things - reorganize the codes for hppa fp registers in opcodes, and add new pa2.0 floating point instructions. Since the pa port is running short on letters to use for opcode fields in include/hppa.h, I took all the fp register codes and gave them a 'f' prefix. The existing 'f' code now uses 'v' instead. This frees up a bunch of codes for other uses if they are needed, and the fp reg codes are a bit easier to read. I did because Jeff Law was trying to convince me to reuse existing codes if I could instead of grabbing new ones because of scarcity. The other change is to add fmpyfadd, fmpynfadd, fneg, and fnegabs pa2.0 opcodes to gas. I have already bootstrapped the latest egcs snapshots with these changes in place and can successfully generate code using the new instructions. -- Jerry Quinn Tel: (514) 761-8737 jquinn@nortelnetworks.com Fax: (514) 761-8505 Speech Recognition Research pa8000.gas.patch.gz From ian@zembu.com Tue Apr 6 15:12:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Tue, 06 Apr 1999 15:12:00 -0000 Subject: Rewrite of relocation overflow checking Message-ID: <19990406221231.16912.qmail@comton.airs.com> I've just checked in a rewrite of the relocation overflow checking, from Chris Torek. Please let me know if you notice any unexpected relocation overflows when working with a newer snapshot. The new code should actually be more conservative in permitting certains valid relocations which the old code rejected, but of course there may be bugs. Ian From donn@interix.com Thu Apr 8 12:16:00 1999 From: donn@interix.com (Donn Terry) Date: Thu, 08 Apr 1999 12:16:00 -0000 Subject: PE patches available Message-ID: <370CFDA7.36716C75@interix.com> Everyone, but DJ and Ian in particular: I have made ftp.interix.com:~ftp/pub/up/binutils.patch.tgz available for anonymous FTP access, with the intent that it be applied to the current greater binutils. (No, you don't want it in the mailing list!) It is a tarball containing a coherent set of patches which have two effects: 1) Add Interix support. 2) Significantly improves the overall support of the MS PE/PEI format (a COFF variant). The effects of the former are obvious. The effects of the latter include: - support for LIB.EXE-generated DLL libraries (and in general compatability with all DLL libraries). - support for COMDAT (although more support may be needed), - a plethora of "little" fixes for various "issues" w.r.t. PE/PEI format, - a rearrangement of the bfd sources so that fewer copies of the PE/PEI functions are needed. (Moving things from coffcode.h, coffswap.h as makes sense.) - nearly complete pass of all ld, gas, and binutils regressions. (And more queued up for later.) (Details with the individual patches.) - some POSIX-ification of binutils commands. - Complete support of intermixed MSVC and gcc-generated objects. (Given the right gdb, there is even limited (line numbers only) support for debugging with MSVC-generated (but ld-linked) object files.) - Improvements to the testsuites. I'm not set up to test this on Cygwin, which is the platform most likely to be affected by these changes (other than Interix, of course). It is possible that I broke something. Thus, I'd ask for testing of these changes by those interested. The patches are all applied with patch -p 5 except toplevel, which is applied with -p 1. (It's identical to a patch applied to egcs. That's generally true of libiberty, as well.) Each patch file contains detailed comments and a ChangeLog entry. The naming convention should be obvious. The leading numbers in the filenames are for my housekeeping and can be ignored (and in general will be sparse). In some cases, it was easier (for various reasons) to generate more than one patch file for the same directory; each has its own comments and ChangeLog; all should be applied. In all cases, the 40.* file is a patch for the testsuite. I have tested the patches against the 0404 tarball. A few line numbers are off slightly, but all patches apply correctly. Coming attractions: With this set of patches applied, it becomes possible to put together another (fairly large) patch that brings the 32-bit (NT) Alpha up to the same level. I also have withheld for the moment some additional patches that are not central to the basic goal of complete PE support. I'll submit those as followups after this batch has stabilized. Ian: yes, I recognize that this is a BIG chunk to chew at once. I've trimmed it quite significantly already. Please be kind in your requests to break it up further. A lot of these patches interact, and breaking them up and still keeping a working set of tools will be very difficult. If there are specific patches that you really need separated I can do that, but I'd request that you make as few such requests as possible, in part because that will delay getting on to the "good stuff" that's queued up behind this. Known compatability (possible) issues: 1) PE is more sensitive to section flag (Characteristics) bits than the current gnu tools (which look at the section name). I've reworked both gas and bfd (the ld part) to make it generate and honor the bits. There may (or may not) be a compatability problem with existing Cygwin binaries. (There should not be any compatability issues w.r.t. existing MSVC binaries.) In testing, look particularly for that (it may reach out an bite you, and it may be subtle, and it may not be a problem at all). If it is a problem, I'll fix it, but I'll need details (and probably a sample file). 2) The meaning of COFF (not stabs) line numbers is subtly different on PE than "pure" COFF; this also affects the .bf, .ef, and .lf pseudo- symbols. My understanding is that I'm the only one who cares about such things in the PE world, and my intent was that regular COFF is unaffected. 3) bfd/04.constructors discusses some interactions between constructors/ destructors and ld -r that should be checked in the Cygwin context. 4) As discussed earlier on this list, theres an issue with MOE and related COFF debug symbols. At the moment, that's left unchanged. -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From donn@interix.com Thu Apr 8 14:02:00 1999 From: donn@interix.com (Donn Terry) Date: Thu, 08 Apr 1999 14:02:00 -0000 Subject: Oops... Message-ID: <370D1865.B3596D6B@interix.com> A last minute cleanup did BAD things to that tar file. New one coming as soon as I can. Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From donn@interix.com Fri Apr 9 09:58:00 1999 From: donn@interix.com (Donn Terry) Date: Fri, 09 Apr 1999 09:58:00 -0000 Subject: Un-Oops. Message-ID: <370E2EB6.FA2A34AC@interix.com> The patches for PE are now back in good shape, as of yesterday afternoon. (If the diff lines for bfd/01.base have filenames on them, and there are no // comments in the files, you have the good one.) Sorry 'bout that. Donn -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From ian@zembu.com Fri Apr 9 18:41:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Fri, 09 Apr 1999 18:41:00 -0000 Subject: gas-990327 snapshot Compile Problem/FIX References: <19990401150159.A30163@sparky.nisa.net> <19990401150159.A30163@sparky.nisa.net> Message-ID: <19990410014117.13945.qmail@daffy.airs.com> Date: Thu, 1 Apr 1999 15:01:59 -0800 From: Jeff Bailey In libiberty/getruntime.c on an i686-pc-gnu system, the compile fails on line 64 with 'HZ' undefined. To fix, I applied the getruntime.c from the egcs-19990328 snapshot which adds the following lines: #if defined (HAVE_TIMES) && ! defined (HZ) #define HZ CLOCKS_PER_SEC #endif Thanks. The egcs version of libiberty moves slowly into the binutils version, and in fact Jeff Law recently did an import, so future binutils snapshots will have that fix. Incidentally, I know there hasn't been a snapshot since last Sunday. There has been a series of unrelated random mishaps. I hope that tonight's snapshot will work. Ian From khan@xraylith.wisc.edu Mon Apr 12 13:40:00 1999 From: khan@xraylith.wisc.edu (Mumit Khan) Date: Mon, 12 Apr 1999 13:40:00 -0000 Subject: PE patches available References: <370CFDA7.36716C75@interix.com> Message-ID: Hi Donn, Ran into a few nits when building for Cygwin -- 1. you mention that you've *put back* the .bss handling, but it's missing from the post-patched ld/scripttempl/pe.sc. I just put it in my hand. 2. bfd/Makefile.in needs peigen.lo as target. Trivial obviously. 3. the $ENTRY in pe.sc expands to __mainCRTStartup, but Cygwin provides _mainCRTStartup. Trivial to fix/make consistent of course. The final executable doesn't work yet, but that I did expect. I'll do some digging to see why it's not loading correctly (under Cygwin or Mingw which uses MS runtime). btw, I always thought that the Makefiles were setup to do the `make headers' automatically in bfd. Guess not. Regards, Mumit From donn@interix.com Tue Apr 13 08:39:00 1999 From: donn@interix.com (Donn Terry) Date: Tue, 13 Apr 1999 08:39:00 -0000 Subject: PE patches available References: Message-ID: <37136122.80BD9A71@interix.com> I've been working with DJ on creating an updated patch. I'm convinced that Menehunes got to at least one copy, because there's no way that some of the problems that are inarguably there could have gotten there without a time warp :-). Anyway, expect a new tarball (over the old one) with these and a number of other problems fixed in a few days. (Everythings fairly straightforward except for another go-around on %^&#$%^^&*()&*(%^&^%*& .idata.) (Mumit: I believe #2 is fixed in what you have, but only in the base files; in this case automake needs to be run to move the change up from Makefile.am to Makefile.in.) I'll send email when it's done. Donn Mumit Khan wrote: > > Hi Donn, > > Ran into a few nits when building for Cygwin -- > > 1. you mention that you've *put back* the .bss handling, but it's missing > from the post-patched ld/scripttempl/pe.sc. I just put it in my hand. > > 2. bfd/Makefile.in needs peigen.lo as target. Trivial obviously. > > 3. the $ENTRY in pe.sc expands to __mainCRTStartup, but Cygwin provides > _mainCRTStartup. Trivial to fix/make consistent of course. > > The final executable doesn't work yet, but that I did expect. I'll do > some digging to see why it's not loading correctly (under Cygwin or > Mingw which uses MS runtime). > > btw, I always thought that the Makefiles were setup to do the `make > headers' automatically in bfd. Guess not. > > Regards, > Mumit -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== From ian@airs.com Tue Apr 13 18:20:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Tue, 13 Apr 1999 18:20:00 -0000 Subject: PE patches available References: Message-ID: <19990413192855.509.qmail@daffy.airs.com> Date: Mon, 12 Apr 1999 15:30:54 -0500 (CDT) From: Mumit Khan btw, I always thought that the Makefiles were setup to do the `make headers' automatically in bfd. Guess not. No, you only get an automatic `make headers' if you configure with --enable-maintainer-mode. If you do that, you must also make sure you have correct versions of autoconf, automake, and gettext in your PATH. Ian From jsm@cygnus.com Thu Apr 15 16:16:00 1999 From: jsm@cygnus.com (Jason Molenda) Date: Thu, 15 Apr 1999 16:16:00 -0000 Subject: Change in the gas2 mailing list setup Message-ID: <19990415161627.A405@cygnus.com> Howdy, I've changed the gas2 mailing list just a bit. The list address used to be gas2@cygnus.com, it is now gas2@sourceware.cygnus.com. Mail sent to the @cygnus.com address will continue to work for the forseeable future. Everyone who was subscribed to gas2@cygnus.com is subscribed to gas2@sourceware.cygnus.com. The way you subscribe and unsubscribe is different. To get off of this list, send a mail note to gas2-unsubscribe@sourceware.cygnus.com. There is a long explanation about how to unsubscribe with this mailing list software (ezmlm+idx) at http://sourceware.cygnus.com/infra/ezman/ezman-1.html#ss1.4 Those of you who follow the EGCS mailing lists should feel at home; gas2 is now using the same list software. There are now web archives for gas2 and mbox formatted archives available by ftp: http://sourceware.cygnus.com/ml/gas2/ ftp://sourceware.cygnus.com/pub/binutils/mail-archives/ Please feel free to e-mail me directly with any questions or concerns. Jason From ian@zembu.com Thu Apr 15 16:36:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Thu, 15 Apr 1999 16:36:00 -0000 Subject: Changes in mailing list setup Message-ID: <19990415233610.3537.qmail@daffy.airs.com> I'd like to publically thank Jason for moving the bfd and gas2 mailing lists over to sourceware.cygnus.com. Among other things, they should now be distributed more quickly. Jason didn't explicitly mention it, but he has moved the old Cygnus-internal mailing list archives over, so the web interface has a long history of messages to the lists. Jason has been doing great work in maintaining sourceware.cygnus.com, which is used by a number of free software projects. As we all know, infrastructure tends to be a thankless job. So although tomorrow he will doubtless return to his obscurity, right now he should bask briefly in the admiration and gratitude of the 50 or so people who read these mailing lists. Cygnus Solutions also deserves our thanks for donating the sourceware.cygnus.com hardware. Ian From rth@cygnus.com Wed May 5 03:37:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Wed, 05 May 1999 03:37:00 -0000 Subject: binutils cvs online Message-ID: <19990505033738.A14701@cygnus.com> We are pleased to announce that binutils is now online with anoncvs access. With this long-overdue change, it joins gcc and gdb in a more open development model. Please visit http://sourceware.cygnus.com/binutils/ for information pertaining to the cvs archive, and mailing lists associated with binutils. r~ From Franz.Sirl-kernel@lauterbach.com Thu May 6 03:48:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 06 May 1999 03:48:00 -0000 Subject: strip looses original file ownership and file permissions Message-ID: <4.2.0.37.19990506124425.03631f00@mail.lauterbach.com> Hi, I just verified that strip out of gas-990418 looses original ownership and permissions of a file. This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC). Is this platform specific or does anybody else notice this? Franz. From Franz.Sirl-kernel@lauterbach.com Thu May 6 04:45:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 06 May 1999 04:45:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506124425.03631f00@mail.lauterbach.com> Message-ID: <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> At 12:48 06.05.99 , Franz Sirl wrote: >Hi, > >I just verified that strip out of gas-990418 looses original ownership and >permissions of a file. >This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC). > >Is this platform specific or does anybody else notice this? After a quick browse through the source I came up with the following untested patch. Does it look right? Franz. Index: rename.c =================================================================== RCS file: /cvs/binutils/binutils/binutils/rename.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 rename.c --- rename.c 1999/05/03 07:29:10 1.1.1.1 +++ rename.c 1999/05/06 11:36:14 @@ -163,29 +163,26 @@ smart_rename (from, to, preserve_dates) #else /* Use rename only if TO is not a symbolic link and has only one hard link. */ - if (exists < 0 || (!S_ISLNK (s.st_mode) && s.st_nlink == 1)) + if (exists == 0 && !S_ISLNK (s.st_mode) && s.st_nlink == 1) { ret = rename (from, to); if (ret == 0) { - if (exists) - { - /* Try to preserve the permission bits and ownership of - TO. First get the mode right except for the setuid - bit. Then change the ownership. Then fix the setuid - bit. We do the chmod before the chown because if the - chown succeeds, and we are a normal user, we won't be - able to do the chmod afterward. We don't bother to - fix the setuid bit first because that might introduce - a fleeting security problem, and because the chown - will clear the setuid bit anyhow. We only fix the - setuid bit if the chown succeeds, because we don't - want to introduce an unexpected setuid file owned by - the user running objcopy. */ - chmod (to, s.st_mode & 0777); - if (chown (to, s.st_uid, s.st_gid) >= 0) - chmod (to, s.st_mode & 07777); - } + /* Try to preserve the permission bits and ownership of + TO. First get the mode right except for the setuid + bit. Then change the ownership. Then fix the setuid + bit. We do the chmod before the chown because if the + chown succeeds, and we are a normal user, we won't be + able to do the chmod afterward. We don't bother to + fix the setuid bit first because that might introduce + a fleeting security problem, and because the chown + will clear the setuid bit anyhow. We only fix the + setuid bit if the chown succeeds, because we don't + want to introduce an unexpected setuid file owned by + the user running objcopy. */ + chmod (to, s.st_mode & 0777); + if (chown (to, s.st_uid, s.st_gid) >= 0) + chmod (to, s.st_mode & 07777); } else { From ian@zembu.com Thu May 6 09:27:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Thu, 06 May 1999 09:27:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> Message-ID: <19990506162706.1409.qmail@daffy.airs.com> Date: Thu, 06 May 1999 13:44:47 +0200 From: Franz Sirl >I just verified that strip out of gas-990418 looses original ownership and >permissions of a file. >This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC). > >Is this platform specific or does anybody else notice this? After a quick browse through the source I came up with the following untested patch. Does it look right? It doesn't look right to me. We need to rename the file FROM to TO. In the normal case of strip, FROM is a temporary file, and TO is the original file which we are stripping. However, this function is also used in other cases. If TO does not exist, we should just use rename. This is not the normal case of strip, but it happens in other cases. Your patch breaks that. That seems to be only significant change in your patch. Perhaps I am missing something. I think the only way to reliably preserve ownership is to avoid using rename. Perhaps the code should be changed to call simple_copy when the owner of the file differs from the effective uid. Ian From Franz.Sirl-kernel@lauterbach.com Thu May 6 09:54:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 06 May 1999 09:54:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <19990506162706.1409.qmail@daffy.airs.com> Message-ID: <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> At 18:27 06.05.99 , Ian Lance Taylor wrote: > Date: Thu, 06 May 1999 13:44:47 +0200 > From: Franz Sirl > > >I just verified that strip out of gas-990418 looses original > ownership and > >permissions of a file. > >This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC). > > > >Is this platform specific or does anybody else notice this? > > After a quick browse through the source I came up with the following > untested patch. Does it look right? > >It doesn't look right to me. > >We need to rename the file FROM to TO. In the normal case of strip, >FROM is a temporary file, and TO is the original file which we are >stripping. However, this function is also used in other cases. > >If TO does not exist, we should just use rename. This is not the >normal case of strip, but it happens in other cases. Your patch >breaks that. That seems to be only significant change in your patch. >Perhaps I am missing something. > >I think the only way to reliably preserve ownership is to avoid using >rename. Perhaps the code should be changed to call simple_copy when >the owner of the file differs from the effective uid. I think my patch produces the behavior that the comments are suggesting. The old code was bogus anyway, cause it tried to chmod/chown "to" after rename with values from a non-existing (exists != 0, this is really a bad-named variable, it's named the opposite of it's meaning) file. Franz. From ian@zembu.com Thu May 6 11:03:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Thu, 06 May 1999 11:03:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> Message-ID: <19990506180307.24286.qmail@daffy.airs.com> Date: Thu, 06 May 1999 18:54:16 +0200 From: Franz Sirl At 18:27 06.05.99 , Ian Lance Taylor wrote: > Date: Thu, 06 May 1999 13:44:47 +0200 > From: Franz Sirl > > >I just verified that strip out of gas-990418 looses original > ownership and > >permissions of a file. > >This is on glibc-2.1.1pre2, Linux-2.2.6 (PPC). > > > >Is this platform specific or does anybody else notice this? > > After a quick browse through the source I came up with the following > untested patch. Does it look right? > >It doesn't look right to me. > >We need to rename the file FROM to TO. In the normal case of strip, >FROM is a temporary file, and TO is the original file which we are >stripping. However, this function is also used in other cases. > >If TO does not exist, we should just use rename. This is not the >normal case of strip, but it happens in other cases. Your patch >breaks that. That seems to be only significant change in your patch. >Perhaps I am missing something. > >I think the only way to reliably preserve ownership is to avoid using >rename. Perhaps the code should be changed to call simple_copy when >the owner of the file differs from the effective uid. I think my patch produces the behavior that the comments are suggesting. The old code was bogus anyway, cause it tried to chmod/chown "to" after rename with values from a non-existing (exists != 0, this is really a bad-named variable, it's named the opposite of it's meaning) file. You're right. I applied the appended patch, which I think should fix the problem. Ian Index: rename.c =================================================================== RCS file: /cvs/binutils/binutils/binutils/rename.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 rename.c --- rename.c 1999/05/03 07:29:10 1.1.1.1 +++ rename.c 1999/05/06 18:02:05 @@ -139,17 +139,17 @@ const char *to; int preserve_dates; { - int exists; + boolean exists; struct stat s; int ret = 0; - exists = lstat (to, &s); + exists = lstat (to, &s) == 0; #if defined (_WIN32) && !defined (__CYGWIN32__) /* Win32, unlike unix, will not erase `to' in `rename(from, to)' but fail instead. Also, chown is not present. */ - if (exists == 0) + if (exists) remove (to); ret = rename (from, to); @@ -163,7 +163,7 @@ #else /* Use rename only if TO is not a symbolic link and has only one hard link. */ - if (exists < 0 || (!S_ISLNK (s.st_mode) && s.st_nlink == 1)) + if (! exists || (!S_ISLNK (s.st_mode) && s.st_nlink == 1)) { ret = rename (from, to); if (ret == 0) From Franz.Sirl-kernel@lauterbach.com Thu May 6 11:43:00 1999 From: Franz.Sirl-kernel@lauterbach.com (Franz Sirl) Date: Thu, 06 May 1999 11:43:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> <19990506180307.24286.qmail@daffy.airs.com> Message-ID: <4.2.0.37.19990506203809.03673a50@mail.lauterbach.com> At 20:03 06.05.99 , Ian Lance Taylor wrote: > I think my patch produces the behavior that the comments are suggesting. > The old code was bogus anyway, cause it tried to chmod/chown "to" after > rename with values from a non-existing (exists != 0, this is really a > bad-named variable, it's named the opposite of it's meaning) file. > >You're right. I applied the appended patch, which I think should fix >the problem. Ok, this works fine, thanks. Btw, have you ever looked at the patch in http://sourceware.cygnus.com/ml/gas2/1999/msg00041.html ? Is it the correct fix for the make check FAIL on powerpc-linux-gnu? Franz. From ian@zembu.com Thu May 6 13:57:00 1999 From: ian@zembu.com (Ian Lance Taylor) Date: Thu, 06 May 1999 13:57:00 -0000 Subject: strip looses original file ownership and file permissions References: <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506133808.0363a9f0@mail.lauterbach.com> <4.2.0.37.19990506183739.0372b0e0@mail.lauterbach.com> <4.2.0.37.19990506203809.03673a50@mail.lauterbach.com> <4.2.0.37.19990506203809.03673a50@mail.lauterbach.com> Message-ID: <19990506205631.27563.qmail@daffy.airs.com> Date: Thu, 06 May 1999 20:42:53 +0200 From: Franz Sirl Btw, have you ever looked at the patch in http://sourceware.cygnus.com/ml/gas2/1999/msg00041.html ? Is it the correct fix for the make check FAIL on powerpc-linux-gnu? No, I don't think it is. I think this is a problem in the glibc dynamic linker. (I looked at glibc 2.0.7; I don't know about other versions.) The GNU linker does not ordinarily create a PT_PHDR program segment for a shared library. This follows the lead of the Solaris linker. When the glibc 2.0.7 dynamic linker does not find a PT_PHDR program segment, it assumes that the program headers may be found at the start of the first PT_LOAD segment. However, ELF does not require this. The comment in the glibc sources (in dl-load.c) says this: /* There was no PT_PHDR specified. We need to find the phdr in the load image ourselves. We assume it is in fact in the load image somewhere, and that the first load command starts at the beginning of the file and thus contains the ELF file header. */ However, I believe the dynamic linker should be able to operate without having the program headers in the load segment at all. What your patch changes is whether the linker puts the program headers at the start of the first PT_LOAD segment. Without your patch, the linker does not put the program headers in loadable memory. With your patch, it does. Since with the current script the program headers are not loaded, the dynamic linker will wind up looking at nonsensical memory for the program headers, and it will fail. However, the dynamic linker does know how to find the correct program headers by reading the file. However, after reading the program headers, it throws them away, and uses the copy which it expects to find in the file. If there is no PT_PHDR segment, it should instead keep and use its own copy. Ian From rth@cygnus.com Thu May 6 15:07:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 15:07:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990505165232.A8594@attis.cs.nmt.edu> Message-ID: <19990506150724.A10994@cygnus.com> On Wed, May 05, 1999 at 04:52:32PM -0600, Cort Dougan wrote: > The signed change at the top makes sense with what the manual says. The > operand in questions should be a 16-bit unsigned immediate value not signed > (as it was before). [...] > /* The SI field in a D form instruction when we accept a wide range > of positive values. */ > #define SISIGNOPT SI + 1 > - { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT }, > + { 16, 0, 0, 0, /*PPC_OPERAND_SIGNED |*/ PPC_OPERAND_SIGNOPT }, Looking at this again, I wonder if this change is correct. Which instruction were you trying to fix? "liu" perhaps? As-is, it affects instructions like "addis", and you can't really add +50000, can you? r~ From rth@cygnus.com Thu May 6 15:32:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 15:32:00 -0000 Subject: ppc 64-bit bridge instructions Message-ID: <19990506153212.A11041@cygnus.com> Cort raised the issue of "64-bit bridge" instructions (whatever that is -- from context, 32-bit only insns that are still valid in 64-bit mode for compatibility). His proposed patch simply moved the affected insns out of "COM32" and "PPC32" to "COM" and "PPC". I'd thought that it would be better to continue marking them in some way, but the categorization that happens in the assembler makes this not quite straightforward. Appended is my proposed patch. Can anyone think of a cleaner way this could be done? r~ * include/opcode/ppc.h (PPC_OPCODE_64_BRIDGE): New. * opcodes/ppc-opc.c (PPC32B, COM32B): New categories. (mtsr, mfsr, mtsrin, mfsrin): Use them. * gas/config/tc-ppc.c (md_parse_option): Recognize -mppc64bridge. (md_begin): Allow bridge insns for ppc64. Index: include/opcode/ppc.h =================================================================== RCS file: /cvs/binutils/binutils/include/opcode/ppc.h,v retrieving revision 1.1.1.1 diff -c -p -d -r1.1.1.1 ppc.h *** ppc.h 1999/05/03 07:29:05 1.1.1.1 --- ppc.h 1999/05/06 22:23:50 *************** extern const int powerpc_num_opcodes; *** 85,90 **** --- 85,93 ---- for the assembler's -many option, and it eliminates duplicates). */ #define PPC_OPCODE_ANY (0200) + /* Opcode is supported as part of the 64-bit bridge. */ + #define PPC_OPCODE_64_BRIDGE (0400) + /* A macro to extract the major opcode from an instruction. */ #define PPC_OP(i) (((i) >> 26) & 0x3f) Index: gas/config/tc-ppc.c =================================================================== RCS file: /cvs/binutils/binutils/gas/config/tc-ppc.c,v retrieving revision 1.1.1.1 diff -c -p -d -r1.1.1.1 tc-ppc.c *** tc-ppc.c 1999/05/03 07:28:43 1.1.1.1 --- tc-ppc.c 1999/05/06 22:23:50 *************** md_parse_option (c, arg) *** 766,771 **** --- 766,776 ---- ppc_cpu = PPC_OPCODE_PPC; ppc_size = PPC_OPCODE_64; } + else if (strcmp (arg, "ppc64bridge") == 0) + { + ppc_cpu = PPC_OPCODE_PPC | PPC_OPCODE_64_BRIDGE; + ppc_size = PPC_OPCODE_64; + } /* -mcom means assemble for the common intersection between Power and PowerPC. At present, we just allow the union, rather than the intersection. */ *************** PowerPC options:\n\ *** 872,877 **** --- 877,883 ---- -mppc, -mppc32, -m403, -m603, -m604\n\ generate code for Motorola PowerPC 603/604\n\ -mppc64, -m620 generate code for Motorola PowerPC 620\n\ + -mppc64bridge generate code for PowerPC 64, including bridge insns\n\ -mcom generate code Power/PowerPC common instructions\n\ -many generate code for any architecture (PWR/PWRX/PPC)\n\ -mregnames Allow symbolic names for registers\n\ *************** md_begin () *** 972,978 **** if ((op->flags & ppc_cpu) != 0 && ((op->flags & (PPC_OPCODE_32 | PPC_OPCODE_64)) == 0 ! || (op->flags & (PPC_OPCODE_32 | PPC_OPCODE_64)) == ppc_size)) { const char *retval; --- 978,986 ---- if ((op->flags & ppc_cpu) != 0 && ((op->flags & (PPC_OPCODE_32 | PPC_OPCODE_64)) == 0 ! || (op->flags & (PPC_OPCODE_32 | PPC_OPCODE_64)) == ppc_size ! || (ppc_size == PPC_OPCODE_64 ! && (op->flags & PPC_OPCODE_64_BRIDGE & ppc_cpu) != 0))) { const char *retval; Index: gas/opcodes/ppc-opc.c =================================================================== RCS file: /cvs/binutils/binutils/opcodes/ppc-opc.c,v retrieving revision 1.1.1.1 diff -c -p -d -r1.1.1.1 ppc-opc.c *** ppc-opc.c 1999/05/03 07:28:59 1.1.1.1 --- ppc-opc.c 1999/05/06 22:23:50 *************** extract_tbr (insn, invalid) *** 1267,1273 **** #define PPC PPC_OPCODE_PPC | PPC_OPCODE_ANY #define PPCCOM PPC_OPCODE_PPC | PPC_OPCODE_COMMON | PPC_OPCODE_ANY #define PPC32 PPC_OPCODE_PPC | PPC_OPCODE_32 | PPC_OPCODE_ANY ! #define PPC64 PPC_OPCODE_PPC | PPC_OPCODE_64 | PPC_OPCODE_ANY #define PPCONLY PPC_OPCODE_PPC #define PPC403 PPC #define PPC750 PPC --- 1267,1274 ---- #define PPC PPC_OPCODE_PPC | PPC_OPCODE_ANY #define PPCCOM PPC_OPCODE_PPC | PPC_OPCODE_COMMON | PPC_OPCODE_ANY #define PPC32 PPC_OPCODE_PPC | PPC_OPCODE_32 | PPC_OPCODE_ANY ! #define PPC32B PPC_OPCODE_PPC | PPC_OPCODE_32 | PPC_OPCODE_ANY | PPC_OPCODE_64_BRIDGE ! #define PPC64 PPC_OPCODE_PPC | PPC_OPCODE_64 | PPC_OPCODE_ANY | PPC_OPCODE_64_BRIDGE #define PPCONLY PPC_OPCODE_PPC #define PPC403 PPC #define PPC750 PPC *************** extract_tbr (insn, invalid) *** 1278,1283 **** --- 1279,1285 ---- #define POWER32 PPC_OPCODE_POWER | PPC_OPCODE_ANY | PPC_OPCODE_32 #define COM PPC_OPCODE_POWER | PPC_OPCODE_PPC | PPC_OPCODE_COMMON | PPC_OPCODE_ANY #define COM32 PPC_OPCODE_POWER | PPC_OPCODE_PPC | PPC_OPCODE_COMMON | PPC_OPCODE_ANY | PPC_OPCODE_32 + #define COM32B PPC_OPCODE_POWER | PPC_OPCODE_PPC | PPC_OPCODE_COMMON | PPC_OPCODE_ANY | PPC_OPCODE_32 | PPC_OPCODE_64_BRIDGE #define M601 PPC_OPCODE_POWER | PPC_OPCODE_601 | PPC_OPCODE_ANY #define PWRCOM PPC_OPCODE_POWER | PPC_OPCODE_601 | PPC_OPCODE_COMMON | PPC_OPCODE_ANY #define MFDEC1 PPC_OPCODE_POWER *************** const struct powerpc_opcode powerpc_opco *** 2249,2255 **** { "addzeo.", XO(31,202,1,1), XORB_MASK, PPCCOM, { RT, RA } }, { "azeo.", XO(31,202,1,1), XORB_MASK, PWRCOM, { RT, RA } }, ! { "mtsr", X(31,210), XRB_MASK|(1<<20), COM32, { SR, RS } }, { "stdcx.", XRC(31,214,1), X_MASK, PPC64, { RS, RA, RB } }, --- 2251,2257 ---- { "addzeo.", XO(31,202,1,1), XORB_MASK, PPCCOM, { RT, RA } }, { "azeo.", XO(31,202,1,1), XORB_MASK, PWRCOM, { RT, RA } }, ! { "mtsr", X(31,210), XRB_MASK|(1<<20), COM32B, { SR, RS } }, { "stdcx.", XRC(31,214,1), X_MASK, PPC64, { RS, RA, RB } }, *************** const struct powerpc_opcode powerpc_opco *** 2293,2299 **** { "mullwo.", XO(31,235,1,1), XO_MASK, PPCCOM, { RT, RA, RB } }, { "mulso.", XO(31,235,1,1), XO_MASK, PWRCOM, { RT, RA, RB } }, ! { "mtsrin", X(31,242), XRA_MASK, PPC32, { RS, RB } }, { "mtsri", X(31,242), XRA_MASK, POWER32, { RS, RB } }, { "dcbtst", X(31,246), XRT_MASK, PPC, { RA, RB } }, --- 2295,2301 ---- { "mullwo.", XO(31,235,1,1), XO_MASK, PPCCOM, { RT, RA, RB } }, { "mulso.", XO(31,235,1,1), XO_MASK, PWRCOM, { RT, RA, RB } }, ! { "mtsrin", X(31,242), XRA_MASK, PPC32B, { RS, RB } }, { "mtsri", X(31,242), XRA_MASK, POWER32, { RS, RB } }, { "dcbtst", X(31,246), XRT_MASK, PPC, { RA, RB } }, *************** const struct powerpc_opcode powerpc_opco *** 2739,2745 **** { "lfsux", X(31,567), X_MASK, COM, { FRT, RAS, RB } }, ! { "mfsr", X(31,595), XRB_MASK|(1<<20), COM32, { RT, SR } }, { "lswi", X(31,597), X_MASK, PPCCOM, { RT, RA, NB } }, { "lsi", X(31,597), X_MASK, PWRCOM, { RT, RA, NB } }, --- 2741,2747 ---- { "lfsux", X(31,567), X_MASK, COM, { FRT, RAS, RB } }, ! { "mfsr", X(31,595), XRB_MASK|(1<<20), COM32B, { RT, SR } }, { "lswi", X(31,597), X_MASK, PPCCOM, { RT, RA, NB } }, { "lsi", X(31,597), X_MASK, PWRCOM, { RT, RA, NB } }, *************** const struct powerpc_opcode powerpc_opco *** 2755,2761 **** { "lfdux", X(31,631), X_MASK, COM, { FRT, RAS, RB } }, ! { "mfsrin", X(31,659), XRA_MASK, PPC32, { RT, RB } }, { "stswx", X(31,661), X_MASK, PPCCOM, { RS, RA, RB } }, { "stsx", X(31,661), X_MASK, PWRCOM, { RS, RA, RB } }, --- 2757,2763 ---- { "lfdux", X(31,631), X_MASK, COM, { FRT, RAS, RB } }, ! { "mfsrin", X(31,659), XRA_MASK, PPC32B, { RT, RB } }, { "stswx", X(31,661), X_MASK, PPCCOM, { RS, RA, RB } }, { "stsx", X(31,661), X_MASK, PWRCOM, { RS, RA, RB } }, From rth@cygnus.com Thu May 6 15:35:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 15:35:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506161159.A27229@attis.cs.nmt.edu> Message-ID: <19990506153554.B10994@cygnus.com> On Thu, May 06, 1999 at 04:11:59PM -0600, Cort Dougan wrote: > } Which instruction were you trying to fix? "liu" perhaps? > } As-is, it affects instructions like "addis", and you can't > } really add +50000, can you? > > You're right, addis takes a signed 16-bit number. Things like lis and oris > take an unsigned 16-bit number, though. They both use SISIGNOPT. Then the right thing to do is make those insns use UI instead. Not having a ppc manual handy, can you provide a complete list of the incorrect instructions? Or better yet, a patch? ;-) r~ From rth@cygnus.com Thu May 6 16:56:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 16:56:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506153554.B10994@cygnus.com> <19990506171639.A26711@attis.cs.nmt.edu> <19990506171639.A26711@attis.cs.nmt.edu> Message-ID: <19990506165624.A24549@cygnus.com> On Thu, May 06, 1999 at 05:16:40PM -0600, Cort Dougan wrote: > Ah-ha! The problem is this: > > We do immediate loads of (for example) 0xffff. Even with lis (which takes > a signed 16-bit value) this works with 32-bit. It shouldn't since 0xffff > is > +32k. When I assemble with -Wa,-mppc64 it doesn't work and complains > that 0xffff is > +32k. > > Eh? Any idea what's going on? In gas/config/tc-ppc.c -- 1067 if ((operand->flags & PPC_OPERAND_SIGNOPT) != 0 1068 && ppc_size == PPC_OPCODE_32) 1069 max = (1 << operand->bits) - 1; Looks like there's some backward compatibility thing going on. You said lis takes a signed value? Meaning that the register gets 0xffffffffffff0000? If so, in my opinion the assembler is correct to bitch at you for 0xffff as an operand. r~ From rth@cygnus.com Thu May 6 17:49:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 17:49:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506153554.B10994@cygnus.com> <19990506171639.A26711@attis.cs.nmt.edu> <19990506165624.A24549@cygnus.com> <19990506180806.A5113@attis.cs.nmt.edu> <19990506180806.A5113@attis.cs.nmt.edu> Message-ID: <19990506174929.A13363@cygnus.com> On Thu, May 06, 1999 at 06:08:06PM -0600, Cort Dougan wrote: > As it is, gcc (32-bit mode) generates > code that will do a lis of 0xffff (the unsigned value) which shouldn't work > according to the manual. When I do this for 64-bit with egcs it will not > assemble. We should fix gcc then. That should not be hard at all. > Right, it should complain for both 32 and 64 bit. It only complains for > 64-bit now, though. So I don't know if I should fix our asm (probably not, > even though according to the manual it's incorrect but gcc generates the > same code). > > If I can change those operands to be unsigned it will still load a 16 bit > value correctly but will allow things to work according to the manual and > the egcs generated code. > > Can we make these critters unsigned? I don't know of any code that > requires they be signed anywhere. I'm not real comfortable just changing it. Who knows what sort of code is out there. I wouldn't be adverse to reducing the error to a warning in 32-bit mode though. r~ From rth@cygnus.com Thu May 6 18:43:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 18:43:00 -0000 Subject: ppc instructions in gas References: <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506153554.B10994@cygnus.com> <19990506171639.A26711@attis.cs.nmt.edu> <19990506165624.A24549@cygnus.com> <19990506180806.A5113@attis.cs.nmt.edu> <19990506174929.A13363@cygnus.com> <19990506185754.A12025@attis.cs.nmt.edu> <19990506185754.A12025@attis.cs.nmt.edu> Message-ID: <19990506184343.C13363@cygnus.com> On Thu, May 06, 1999 at 06:57:54PM -0600, Cort Dougan wrote: > } We should fix gcc then. That should not be hard at all. > > Ok. Patch gcc to emit correct code and modify the asm we have in the > kernel? Know of any cute gas methods of converting 0xffff and its ilk to a > signed value? Pardon? "gas methods"? > } I'm not real comfortable just changing it. Who knows what sort > } of code is out there. I wouldn't be adverse to reducing the > } error to a warning in 32-bit mode though. > > I'd prefer to actually do the right thing in my asm and if gcc did the same > that would all the better. So the check in binutils to allow unsigned > values is probably a workaround for gcc? No, the check to allow unsigned values is a workaround for (to pick a name out of the hat) NorTel's hand-written assembly code. So I'm on the right page, "lis" is the only instruction this is an issue for? What about the old "liu" insn? "U" presumably stood for "upper" not "unsigned"? r~ From rth@cygnus.com Thu May 6 19:50:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 19:50:00 -0000 Subject: type correctness tweek Message-ID: <19990506194959.A14761@cygnus.com> Gas won't build with the metrowerks compiler, because we passed an unsigned char* to strcpy, which expects char*. I took this opportunity to not do two passes across the string. r~ * symbols.c (symbol_find_base): Use memcpy instead of strcpy. Don't copy before downcaseing. Index: symbols.c =================================================================== RCS file: /cvs/binutils/binutils/gas/symbols.c,v retrieving revision 1.1.1.1 diff -c -p -d -r1.1.1.1 symbols.c *** symbols.c 1999/05/03 07:28:41 1.1.1.1 --- symbols.c 1999/05/07 02:46:34 *************** symbol_find_base (name, strip_underscore *** 456,478 **** #ifdef tc_canonicalize_symbol_name { char *copy; ! copy = (char *) alloca (strlen (name) + 1); ! strcpy (copy, name); name = tc_canonicalize_symbol_name (copy); } #endif if (! symbols_case_sensitive) { ! unsigned char *copy; ! copy = (unsigned char *) alloca (strlen (name) + 1); ! strcpy (copy, name); ! name = (const char *) copy; ! for (; *copy != '\0'; copy++) ! if (islower (*copy)) ! *copy = toupper (*copy); } return ((symbolS *) hash_find (sy_hash, name)); --- 456,485 ---- #ifdef tc_canonicalize_symbol_name { char *copy; + size_t len = strlen (name) + 1; ! copy = (char *) alloca (len); ! memcpy (copy, name, len); name = tc_canonicalize_symbol_name (copy); } #endif if (! symbols_case_sensitive) { ! char *copy; ! const char *orig; ! unsigned char c; ! orig = name; ! name = copy = (char *) alloca (strlen (name) + 1); ! ! while ((c = *orig++) != '\0') ! { ! if (islower (c)) ! c = toupper (c); ! *copy++ = c; ! } ! *copy = '\0'; } return ((symbolS *) hash_find (sy_hash, name)); From ian@airs.com Thu May 6 20:06:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Thu, 06 May 1999 20:06:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506150724.A10994@cygnus.com> Message-ID: <19990507030530.10843.qmail@daffy.airs.com> Date: Thu, 6 May 1999 15:07:24 -0700 From: Richard Henderson On Wed, May 05, 1999 at 04:52:32PM -0600, Cort Dougan wrote: > The signed change at the top makes sense with what the manual says. The > operand in questions should be a 16-bit unsigned immediate value not signed > (as it was before). [...] > /* The SI field in a D form instruction when we accept a wide range > of positive values. */ > #define SISIGNOPT SI + 1 > - { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT }, > + { 16, 0, 0, 0, /*PPC_OPERAND_SIGNED |*/ PPC_OPERAND_SIGNOPT }, Looking at this again, I wonder if this change is correct. Which instruction were you trying to fix? "liu" perhaps? As-is, it affects instructions like "addis", and you can't really add +50000, can you? We specifically want to accept a wide range of values, because users in practice use a wide range of values. That is, users in practice use lis 4,-0x8000 lis 4,0x7fff lis 4,0xffff lis 4,-1 and expect them all to work. It's true that the PowerPC docs prohibit the last one. However, people use it in real code, so gas accepts it. The last two instructions above generate the same bytes. I don't have the context of the original message. The addis/lis instruction is documented to take a signed operand. I don't know why it makes sense to remove PPC_OPERAND_SIGNED. Ian From rth@cygnus.com Thu May 6 20:13:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Thu, 06 May 1999 20:13:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990507030530.10843.qmail@daffy.airs.com> <19990507030530.10843.qmail@daffy.airs.com> Message-ID: <19990506201322.A14952@cygnus.com> On Fri, May 07, 1999 at 03:05:30AM -0000, Ian Lance Taylor wrote: > I don't have the context of the original message. The addis/lis > instruction is documented to take a signed operand. I don't know why > it makes sense to remove PPC_OPERAND_SIGNED. Context is that gcc doesn't emit signed, and some of the ppc linux kernel sources don't use signed values either. This worked for ppc32 due to the PPC_OPERAND_SIGNOPT hack, and only showed up when Cort started work on ppc64. We iterated enough to conclude that we should in fact fix gcc, and the kernel sources. The one remaining question is whether to continue to silently accept unsigned values for ppc32, or whether we should warn for them. Thoughts on that last? r~ From ian@airs.com Thu May 6 20:43:00 1999 From: ian@airs.com (Ian Lance Taylor) Date: Thu, 06 May 1999 20:43:00 -0000 Subject: ppc instructions in gas References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990507030530.10843.qmail@daffy.airs.com> <19990506201322.A14952@cygnus.com> <19990506201322.A14952@cygnus.com> Message-ID: <19990507034233.10892.qmail@daffy.airs.com> Date: Thu, 6 May 1999 20:13:22 -0700 From: Richard Henderson On Fri, May 07, 1999 at 03:05:30AM -0000, Ian Lance Taylor wrote: > I don't have the context of the original message. The addis/lis > instruction is documented to take a signed operand. I don't know why > it makes sense to remove PPC_OPERAND_SIGNED. Context is that gcc doesn't emit signed, and some of the ppc linux kernel sources don't use signed values either. This worked for ppc32 due to the PPC_OPERAND_SIGNOPT hack, and only showed up when Cort started work on ppc64. We iterated enough to conclude that we should in fact fix gcc, and the kernel sources. The one remaining question is whether to continue to silently accept unsigned values for ppc32, or whether we should warn for them. Thoughts on that last? I believe we should continue to silently accept them. The patch was put in there because of existing code which should continue to work. I now remember that I opposed it at the time, and argued David Edelsohn (I believe it was) into only accepting unsigned values in 32 bit mode, and requiring people to fix their code as they upgraded to 64 bits. I even have a vague recollection that the Power liu instruction was documented to load an unsigned value. The Power was only 32 bits, so of course it didn't really matter. The PowerPC renamed liu to lis, and made it signed for the 64 bit version. Power code and Power programmers naturally used unsigned values, so we made gas permit unsigned values for lis. Ian From rth@cygnus.com Sat May 8 15:18:00 1999 From: rth@cygnus.com (Richard Henderson) Date: Sat, 08 May 1999 15:18:00 -0000 Subject: [davidm@hpl.hp.com: .debug_line patch] Message-ID: <19990508151812.A22602@cygnus.com> ----- Forwarded message from David Mosberger ----- Date: Sat, 8 May 1999 14:49:15 -0700 Message-Id: <199905082149.OAA28668@napali.hpl.hp.com> From: David Mosberger To: rth@cygnus.com Subject: .debug_line patch X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Reply-to: davidm@hpl.hp.com Hi Richard, This took a bit longer to debug than expected, but here it is: the patch is relative to the gas-990404 snapshot (unfortunately, this includes the 32-bit cleanups I sent you earlier, but I hope it won't be too much trouble to filter those out). What it does: - fix some bugs in bfd/dwarf2.c and makes it more robust against bad .debug_line sections - add the necessary machinery for generating .debug_line in the assembler - modifies egcs/gcc/dwarf2out.c so that it leaves .debug_line generation to the assembler (via .file & .loc) if macro ASM_DWARF2_LINE_DEBUG_INFO is defined Perhaps dwarf2dbg.c is too big a change to accept without an assignment form, but at least you can take a look at it and let me know what you think. The other changes are hopefully small enough not to require an assignment (I'm still waiting for the final version of the corporate assignment). Some caveats: o egcs currently passes the line info to the assembler in a very naive (space-wasting) way: one .file/.loc directive per line! ;-) Easy to fix, but I just wanted something that's simple and reliable for now o disassembling handcrafted assembly files that were translated with -gdwarf2 still doesn't work; I think the best way to fix this is to change dwarf2dbg.c:dwarf2_finish() to check if .debug_info exists and, if not, generate a small .debug_info section good enough for bfd/dwarf2.c to do its job o disassembling object files (as opposed to executables) still doesn't work perfectly (though better than before); as the comment in bfd/dwarf2.c suggests, fixing this would require looking at the relocs Note that with dwarf2dbg.c, You can invoke the assembler with -D to get some statistics on the effectiveness of the .debug_line info. For the IA-64 GNU libc, the size of .debug_line dropped from 1,223 KB to 143 KB so it's definitely worthwhile! ;-) I didn't test this on anything but IA-64. It would be interesting to see how the assembler holds up when used with another compiler that has DWARF2 support. --david --------------------------------------------------------------------- gas-990404-lia/gas/ChangeLog Fri May 7 17:41:43 1999 1999-05-07 David Mosberger * as.c (parse_args): Add option -gdwarf2 to allow requesting DWARF2 debug info (line information only, at this point). * as.h: Update comment about supported debug formats. * dwarf2dbg.h: New file. * dwarf2dbg.c: New file. --------------------------------------------------------------------- gas-990404-lia/bfd/ChangeLog Fri May 7 16:48:22 1999 1999-05-07 David Mosberger * dwarf2.c (decode_line_info): Initialize table->files and table->last_line to NULL to avoid segfaults due to random values in these members. (concat_filename): Check for out-of-range file number before indexing filename table. Segfaults suck. --------------------------------------------------------------------- egcs-1.1.2-lia/gcc/ChangeLog Fri May 7 15:04:30 1999 Sat May 8 14:36:43 1999 David Mosberger * dwarf2out.c (print_dwarf_line_table, size_of_line_prolog, sizeof_of_line_info, output_line_info): Declare and define only if macro ASM_DWARF2_LINE_DEBUG_INFO is not defined. (debug_dwarf): Call print_dwarf_line_table() only if ASM_DWARF2_LINE_DEBUG_INFO is not defined. (dwarf2out_line) [ASM_DWARF2_LINE_DEBUG_INFO]: Use .file and .loc directives to pass line information to assembler (current implementation is naive and not very compact...). (dwarf2out_finish) [ASM_DWARF2_LINE_DEBUG_INFO]: Instead of generating full .debug_line section, only generate DW_AT_stmt_list entry if .debug_line is non-empty. --------------------------------------------------------------------- diff -urN gas-990404/bfd/dwarf2.c gas-990404-lia/bfd/dwarf2.c --- gas-990404/bfd/dwarf2.c Sun Apr 4 01:12:58 1999 +++ gas-990404-lia/bfd/dwarf2.c Sat May 8 13:35:03 1999 @@ -677,7 +677,16 @@ struct line_info_table* table; unsigned int file; { - char* filename = table->files[file - 1].name; + char* filename; + + if (file - 1 >= table->num_files) + { + (*_bfd_error_handler) (_("Dwarf Error: mangled line number " + "section (bad file number).")); + return ""; + } + + filename = table->files[file - 1].name; if (*filename == '/') return filename; @@ -708,6 +717,7 @@ unsigned int i, bytes_read; char *cur_file, *cur_dir; unsigned char op_code, extended_op, adj_opcode; + bfd_vma hi_pc = 0, lo_pc = ~ (bfd_vma) 0; if (! dwarf_line_buffer) { @@ -747,6 +757,9 @@ table->num_dirs = 0; table->dirs = NULL; + table->files = NULL; + table->last_line = NULL; + line_ptr = dwarf_line_buffer + unit->line_offset; /* read in the prologue */ @@ -831,6 +844,7 @@ int is_stmt = lh.default_is_stmt; int basic_block = 0; int end_sequence = 0; + boolean first_time = true; /* Decode the table. */ while (! end_sequence) @@ -851,7 +865,6 @@ break; case DW_LNE_set_address: address = read_address (unit, line_ptr); - address &= 0xffffffff; line_ptr += unit->addr_size; break; case DW_LNE_define_file: @@ -919,7 +932,8 @@ basic_block = 1; break; case DW_LNS_const_add_pc: - address += (255 - lh.opcode_base) / lh.line_range; + address += lh.minimum_instruction_length + * ((255 - lh.opcode_base) / lh.line_range); break; case DW_LNS_fixed_advance_pc: address += read_2_bytes (abfd, line_ptr); @@ -934,8 +948,20 @@ add_line_info (table, address, filename, line, column); basic_block = 1; } + if (unit->high == 0) + { + if (address > hi_pc) + hi_pc = address; + if (address < lo_pc) + lo_pc = address; + } } } + if (unit->high == 0 && hi_pc != 0) + { + unit->high = hi_pc; + unit->low = lo_pc; + } return table; } @@ -1005,8 +1031,7 @@ each_func; each_func = each_func->prev_func) { - if (addr >= (each_func->low & 0xffffffff) - && addr < (each_func->high & 0xffffffff)) + if (addr >= each_func->low && addr < each_func->high) { *functionname_ptr = each_func->name; return true; @@ -1274,8 +1299,7 @@ bfd_vma addr; { return ! unit->error - && ( addr >= (unit->low & 0xffffffff) - && addr <= (unit->high & 0xffffffff)); + && (addr >= unit->low && addr <= unit->high); } @@ -1366,6 +1390,8 @@ struct comp_unit* each; + boolean found; + *filename_ptr = NULL; *functionname_ptr = NULL; *linenumber_ptr = 0; @@ -1407,14 +1433,20 @@ stash->info_ptr_end = stash->info_ptr + size; - /* FIXME: There is a problem with the contents of the .debug_info section. - The 'low' and 'high' addresses of the comp_units are computed by relocs - against symbols in the .text segment. We need these addresses in - order to determine the nearest line number, and so we have to resolve - the relocs. There is a similar problem when the .debug_line section is - processed as well. + /* FIXME: There is a problem with the contents of the + .debug_info section. The 'low' and 'high' addresses of the + comp_units are computed by relocs against symbols in the + .text segment. We need these addresses in order to determine + the nearest line number, and so we have to resolve the + relocs. There is a similar problem when the .debug_line + section is processed as well (e.g., there may be relocs + against the operand of the DW_LNE_set_address operator). - Unfortunately getting hold of the reloc information is hard... */ + Unfortunately getting hold of the reloc information is hard... + + For now, this means that disassembling object files (as + opposed to fully executables) does not always work as well as + we would like. */ } /* A null info_ptr indicates that there is no dwarf2 info @@ -1454,11 +1486,28 @@ each->next_unit = stash->all_comp_units; stash->all_comp_units = each; - if (comp_unit_contains_address (each, addr)) - return comp_unit_find_nearest_line (each, addr, - filename_ptr, - functionname_ptr, - linenumber_ptr); + /* DW_AT_low_pc and DW_AT_high_pc are optional for + compilation units. If we don't have them (i.e., + unit->high == 0), we need to consult the line info + table to see if a compilation unit contains the given + address. */ + if (each->high > 0) + { + if (comp_unit_contains_address (each, addr)) + return comp_unit_find_nearest_line (each, addr, + filename_ptr, + functionname_ptr, + linenumber_ptr); + } + else + { + found = comp_unit_find_nearest_line (each, addr, + filename_ptr, + functionname_ptr, + linenumber_ptr); + if (found) + return true; + } } } } diff -urN gas-990404/gas/as.c gas-990404-lia/gas/as.c --- gas-990404/gas/as.c Sun Apr 4 01:10:22 1999 +++ gas-990404-lia/gas/as.c Fri May 7 17:58:39 1999 @@ -365,7 +366,9 @@ #define OPTION_STRIP_LOCAL_ABSOLUTE (OPTION_STD_BASE + 15) {"strip-local-absolute", no_argument, NULL, OPTION_STRIP_LOCAL_ABSOLUTE}, #define OPTION_TRADITIONAL_FORMAT (OPTION_STD_BASE + 16) - {"traditional-format", no_argument, NULL, OPTION_TRADITIONAL_FORMAT} + {"traditional-format", no_argument, NULL, OPTION_TRADITIONAL_FORMAT}, +#define OPTION_GDWARF2 (OPTION_STD_BASE + 17) + {"gdwarf2", no_argument, NULL, OPTION_GDWARF2} }; /* Construct the option lists from the standard list and the @@ -546,6 +549,10 @@ debug_type = DEBUG_STABS; break; + case OPTION_GDWARF2: + debug_type = DEBUG_DWARF2; + break; + case 'J': flag_signed_overflow_ok = 1; break; diff -urN gas-990404/gas/as.h gas-990404-lia/gas/as.h --- gas-990404/gas/as.h Sun Apr 4 01:10:22 1999 +++ gas-990404-lia/gas/as.h Fri May 7 17:35:37 1999 @@ -454,7 +454,7 @@ extern int listing; /* Type of debugging information we should generate. We currently - only support stabs and ECOFF. */ + support stabs, ECOFF, and DWARF2. */ enum debug_info_type { diff -urN gas-990404/gas/dwarf2dbg.c gas-990404-lia/gas/dwarf2dbg.c --- gas-990404/gas/dwarf2dbg.c Wed Dec 31 16:00:00 1969 +++ gas-990404-lia/gas/dwarf2dbg.c Sat May 8 13:30:29 1999 @@ -0,0 +1,612 @@ +/* dwarf2dbg.c - DWARF2 debug support + Copyright (C) 1999 Hewlett-Packard Co + Contributed by David Mosberger-Tang + + This file is part of GAS, the GNU Assembler. + + GAS is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GAS is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GAS; see the file COPYING. If not, write to the Free + Software Foundation, 59 Temple Place - Suite 330, Boston, MA + 02111-1307, USA. + + Logical line numbers can be controlled by the compiler via the + following two directives: + + .file FILENO "file.c" + .loc FILENO LINENO [COLUMN] + + FILENO is the filenumber. */ + +#include "ansidecl.h" + +#include "as.h" +#include "dwarf2dbg.h" +#include "subsegs.h" + +#include + +#define BYTES_PER_ADDRESS (BFD_ARCH_SIZE / 8) + +/* Since we can't generate the prolog until the body is complete, we + use three different subsegments for .debug_line: one holding the + prolog, one for the directory and filename info, and one for the + body ("statement program"). */ +#define DL_PROLOG 0 +#define DL_FILES 1 +#define DL_BODY 2 + +/* First special line opcde - leave room for the standard opcodes. + Note: If you want to change this, you'll have to update the + "standard_opcode_lengths" table that is emitted below in + dwarf2_finish(). */ +#define DWARF2_LINE_OPCODE_BASE 10 + +#ifndef DWARF2_LINE_BASE + /* Minimum line offset in a special line info. opcode. This value + was chosen to give a reasonable range of values. */ +# define DWARF2_LINE_BASE -5 +#endif + +/* Range of line offsets in a special line info. opcode. */ +#ifndef DWARF2_LINE_RANGE +# define DWARF2_LINE_RANGE 14 +#endif + +#ifndef DWARF2_LINE_MIN_INSN_LENGTH + /* Define the architecture-dependent minimum instruction length (in + bytes). This value should be rather too small than too big. */ +# define DWARF2_LINE_MIN_INSN_LENGTH 4 +#endif + +/* Flag that indicates the initial value of the is_stmt_start flag. + In the present implementation, we do not mark any lines as + the beginning of a source statement, because that information + is not made available by the GCC front-end. */ +#define DWARF2_LINE_DEFAULT_IS_STMT 1 + +/* Flag that indicates the initial value of the is_stmt_start flag. + In the present implementation, we do not mark any lines as + the beginning of a source statement, because that information + is not made available by the GCC front-end. */ +#define DWARF2_LINE_DEFAULT_IS_STMT 1 + +/* Given a special op, return the line skip amount: */ +#define SPECIAL_LINE(op) \ + (((op) - DWARF2_LINE_OPCODE_BASE)%DWARF2_LINE_RANGE + DWARF2_LINE_BASE) + +/* Given a special op, return the address skip amount (in units of + DWARF2_LINE_MIN_INSN_LENGTH. */ +#define SPECIAL_ADDR(op) (((op) - DWARF2_LINE_OPCODE_BASE)/DWARF2_LINE_RANGE) + +/* The maximum address skip amont that can be encoded with a special op: */ +#define MAX_SPECIAL_ADDR_DELTA SPECIAL_ADDR(255) + +static struct + { + /* state machine state as per DWARF2 manual: */ + bfd_vma addr; + segT text_seg; /* text segment "addr" is relative to */ + subsegT text_subseg; + unsigned int filenum; + unsigned int line; + unsigned int column; + unsigned int + is_stmt : 1, + basic_block : 1, + any_dwarf2_directives : 1; + + segT line_seg; /* ".debug_line" segment */ + int last_filename; /* index of last filename that was used */ + int num_filenames; /* index of last filename in use */ + int filename_len; /* length of the filename array */ + struct + { + int dir; /* valid after gen_dir_list() only */ + char *name; /* full path before gen_dir_list(), filename afterwards */ + } + *file; + + struct dwarf2_line_info current; /* current source info: */ + + /* counters for statistical purposes: */ + unsigned int num_line_entries; + unsigned int opcode_hist[256]; /* histogram of opcode frequencies */ + } +ls = + { + /* initialize as per DWARF2.0 standard: */ + 0, /* address */ + NULL, /* text_seg */ + 0, /* text_subseg */ + 1, /* file */ + 1, /* line */ + 0, /* column */ + DWARF2_LINE_DEFAULT_IS_STMT, /* is_stmt */ + 0, /* basic_block */ + }; + +#define out_byte(byte) FRAG_APPEND_1_CHAR(byte) +#define out_opcode(opc) (out_byte ((opc)), ++ls.opcode_hist[(opc) & 0xff]) + +/* Output an unsigned "little-endian base 128" number. */ +static void +out_uleb128 (bfd_vma value) +{ + unsigned char byte, more = 0x80; + + do + { + byte = value & 0x7f; + value >>= 7; + if (value == 0) + more = 0; + out_byte (more | byte); + } + while (more); +} + +/* Output a signed "little-endian base 128" number. */ +static void +out_sleb128 (bfd_signed_vma value) +{ + unsigned char byte, more = 0x80; + + do + { + byte = value & 0x7f; + value >>= 7; + if (((value == 0) && ((byte & 0x40) == 0)) + || ((value == -1) && ((byte & 0x40) != 0))) + more = 0; + out_byte (more | byte); + } + while (more); +} + +/* Set an absolute address (may results in a relocation entry): */ +static void +out_set_addr (bfd_vma addr) +{ + subsegT saved_subseg; + segT saved_seg; + expressionS expr; + symbolS *sym; + + saved_seg = now_seg; + saved_subseg = now_subseg; + subseg_set (ls.text_seg, ls.text_subseg); + + sym = symbol_new (".L0\001", now_seg, addr, frag_now); + + subseg_set (saved_seg, saved_subseg); + + out_opcode (DW_LNS_extended_op); + out_uleb128 (BYTES_PER_ADDRESS + 1); + + out_opcode (DW_LNE_set_address); + expr.X_op = O_symbol; + expr.X_add_symbol = sym; + expr.X_add_number = 0; + emit_expr (&expr, BYTES_PER_ADDRESS); +} + +/* Look up a filenumber either by filename or by filenumber. If both + a filenumber and a filename are specified, lookup by filename takes + precedence. If the filename cannot be found, it is added to the + filetable the filenumber for the new entry is returned. */ +static int +get_filenum (int filenum, char *file) +{ + int i, last = filenum - 1; + char char0 = file[0]; + + if ((unsigned) last >= ls.num_filenames) + last = ls.last_filename; + + /* do a quick check against the previously used filename: */ + if (ls.num_filenames > 0 && ls.file[last].name[0] == char0 + && strcmp (ls.file[last].name + 1, file + 1) == 0) + return last + 1; + + /* no match, fall back to simple linear scan: */ + for (i = 0; i < ls.num_filenames; ++i) + { + if (ls.file[i].name[0] == char0 + && strcmp (ls.file[i].name + 1, file + 1) == 0) + { + ls.last_filename = i; + return i + 1; + } + } + + /* no match: enter new filename */ + if (ls.num_filenames >= ls.filename_len) + { + ls.filename_len += 13; + ls.file = xrealloc (ls.file, ls.filename_len * sizeof (ls.file[0])); + } + ls.file[ls.num_filenames].dir = 0; + ls.file[ls.num_filenames].name = file; + return ++ls.num_filenames; +} + +/* Encode a pair of line and address skips as efficiently as possible. + Note that the line skip is signed, whereas the address skip is + unsigned. */ +static void +gen_addr_line (int line_delta, bfd_vma addr_delta) +{ + unsigned int tmp, opcode; + + tmp = line_delta - DWARF2_LINE_BASE; + + if (tmp >= DWARF2_LINE_RANGE) + { + out_opcode (DW_LNS_advance_line); + out_sleb128 (line_delta); + tmp = 0 - DWARF2_LINE_BASE; + line_delta = 0; + } + + tmp += DWARF2_LINE_OPCODE_BASE; + + /* try using a special opcode: */ + opcode = tmp + addr_delta*DWARF2_LINE_RANGE; + if (opcode <= 255) + { + out_opcode (opcode); + return; + } + + /* try using DW_LNS_const_add_pc followed by special op: */ + opcode = tmp + (addr_delta - MAX_SPECIAL_ADDR_DELTA)*DWARF2_LINE_RANGE; + if (opcode <= 255) + { + out_opcode (DW_LNS_const_add_pc); + out_opcode (opcode); + return; + } + + out_opcode (DW_LNS_advance_pc); + out_uleb128 (addr_delta); + + if (line_delta) + out_opcode (tmp); /* output line-delta */ + else + out_opcode (DW_LNS_copy); /* append new row with current info */ +} + +void +dwarf2_gen_line_info (bfd_vma addr, struct dwarf2_line_info *l) +{ + unsigned int filenum = l->filenum; + unsigned int any_output = 0; + subsegT saved_subseg; + segT saved_seg; + char *frag; + + if (flag_debug) + fprintf (stderr, "line: addr %llx file `%s' line %u col %u flags %lx\n", + (long long) addr, l->filename, l->line, l->column, l->flags); + + if (filenum > 0 && !l->filename) + { + if (filenum >= ls.num_filenames) + { + as_warn ("Encountered bad file number in line number debug info!"); + return; + } + } + else if (l->filename) + filenum = get_filenum (filenum, l->filename); + else + return; /* no filename, no filnum => no play */ + + if (!ls.line_seg) + { + symbolS *secsym; + + ls.line_seg = subseg_get (".debug_line", DL_BODY); + bfd_set_section_flags (stdoutput, ls.line_seg, SEC_READONLY); + secsym = symbol_find (".debug_line"); + if (secsym) + secsym->bsym = ls.line_seg->symbol; + else + symbol_table_insert (section_symbol (ls.line_seg)); + } + + saved_seg = now_seg; + saved_subseg = now_subseg; + subseg_set (ls.line_seg, DL_BODY); + + if (ls.text_seg != saved_seg || ls.text_subseg != saved_subseg) + { + any_output = 1; + ls.text_seg = saved_seg; + ls.text_subseg = saved_subseg; + out_set_addr (addr); + } + + if (ls.filenum != filenum) + { + any_output = 1; + out_opcode (DW_LNS_set_file); + out_uleb128 (filenum); + ls.filenum = filenum; + } + + if (ls.column != l->column) + { + any_output = 1; + out_opcode (DW_LNS_set_column); + out_uleb128 (l->column); + ls.column = l->column; + } + + if (((l->flags & DWARF2_FLAG_BEGIN_STMT) != 0) != ls.is_stmt) + { + any_output = 1; + out_opcode (DW_LNS_negate_stmt); + } + + if (l->flags & DWARF2_FLAG_BEGIN_BLOCK) + { + any_output = 1; + out_opcode (DW_LNS_set_basic_block); + } + + if (ls.line != l->line) + { + any_output = 1; + if (addr < ls.addr) + { + out_set_addr (addr); + ls.addr = addr; + } + gen_addr_line (l->line - ls.line, + (addr - ls.addr) / DWARF2_LINE_MIN_INSN_LENGTH); + ls.basic_block = 0; + ls.line = l->line; + ls.addr = addr; + } + + subseg_set (saved_seg, saved_subseg); + + ls.num_line_entries += any_output; +} + +static void +gen_dir_list (void) +{ + char *str, *slash, *dir_list, *dp, *cp; + int i, j, num_dirs; + + dir_list = frag_more (0); + num_dirs = 0; + + for (i = 0; i < ls.num_filenames; ++i) + { + str = ls.file[i].name; + slash = strrchr (str, '/'); + if (slash) + { + *slash = '\0'; + for (j = 0, dp = dir_list; j < num_dirs; ++j) + { + if (strcmp (str, dp) == 0) + { + ls.file[i].dir = j; + break; + } + dp += strlen (dp); + } + if (j >= num_dirs) + { + /* didn't find this directory: append it to the list */ + size_t size = strlen (str) + 1; + cp = frag_more (size); + memcpy (cp, str, size); + ls.file[i].dir = ++num_dirs; + } + *slash = '/'; + ls.file[i].name = slash + 1; + } + } + out_byte ('\0'); /* terminate directory list */ +} + +static void +gen_file_list (void) +{ + size_t size; + char *cp; + int i; + + for (i = 0; i < ls.num_filenames; ++i) + { + size = strlen (ls.file[i].name) + 1; + cp = frag_more (size); + memcpy (cp, ls.file[i].name, size); + + out_uleb128 (ls.file[i].dir); /* directory number */ + out_uleb128 (0); /* last modification timestamp */ + out_uleb128 (0); /* filesize */ + } + out_byte (0); /* terminate filename list */ +} + +void +print_stats (unsigned long total_size) +{ + static const char *opc_name[] = + { + "extended", "copy", "advance_pc", "advance_line", "set_file", + "set_column", "negate_stmt", "set_basic_block", "const_add_pc", + "fixed_advance_pc" + }; + int i, j; + + fprintf (stderr, "Average size: %g bytes/line\n", + total_size / (double) ls.num_line_entries); + + fprintf (stderr, "\nStandard opcode histogram:\n"); + + for (i = 0; i < sizeof (opc_name)/sizeof (opc_name[0]); ++i) + { + fprintf (stderr, "%s", opc_name[i]); + for (j = strlen (opc_name[i]); j < 16; ++j) + fprintf (stderr, " "); + fprintf (stderr, ": %u\n", ls.opcode_hist[i]); + } + + fprintf (stderr, "\nSpecial opcodes:\naddr\t\t\t\tline skip\n"); + + fprintf (stderr, "skip: "); + for (j = DWARF2_LINE_BASE; j < DWARF2_LINE_BASE + DWARF2_LINE_RANGE; ++j) + fprintf (stderr, "%3d", j); + fprintf (stderr, "\n-----"); + + for (; i < 256; ++i) + { + j = SPECIAL_LINE (i); + if (j == DWARF2_LINE_BASE) + fprintf (stderr, "\n%4u: ", + DWARF2_LINE_MIN_INSN_LENGTH*SPECIAL_ADDR (i)); + fprintf (stderr, " %2u", ls.opcode_hist[i]); + } + fprintf (stderr, "\n"); +} + +void +dwarf2_finish (void) +{ + bfd_vma addr, body_size, total_size, prolog_size; + subsegT saved_subseg, line_prolog; + segT saved_seg; + char *cp; + + if (!ls.line_seg) + /* no .debug_line segment, no work to do... */ + return; + + saved_seg = now_seg; + saved_subseg = now_subseg; + + /* end .debug_line with end_sequence: */ + if (ls.text_seg) + { + subseg_set (ls.text_seg, ls.text_subseg); + addr = frag_now_fix (); + subseg_set (ls.line_seg, DL_BODY); + gen_addr_line (0, (addr - ls.addr) / DWARF2_LINE_MIN_INSN_LENGTH); + } + subseg_set (ls.line_seg, DL_BODY); + out_opcode (DW_LNS_extended_op); + out_uleb128 (1); + out_byte (DW_LNE_end_sequence); + total_size = body_size = frag_now_fix (); + + /* now generate the directory and file lists: */ + subseg_set (ls.line_seg, DL_FILES); + gen_dir_list (); + gen_file_list (); + total_size += frag_now_fix (); + + /* and now the header ("statement program prolog", in DWARF2 lingo...) */ + subseg_set (ls.line_seg, DL_PROLOG); + + cp = frag_more (15 + DWARF2_LINE_OPCODE_BASE - 1); + + total_size += frag_now_fix (); + prolog_size = total_size - body_size - 10; + +# define STUFF(val,size) md_number_to_chars (cp, val, size); cp += size; + STUFF (total_size - 4, 4); /* length */ + STUFF (2, 2); /* version */ + STUFF (prolog_size, 4); /* prologue_length */ + STUFF (DWARF2_LINE_MIN_INSN_LENGTH, 1); + STUFF (DWARF2_LINE_DEFAULT_IS_STMT, 1); + STUFF (DWARF2_LINE_BASE, 1); + STUFF (DWARF2_LINE_RANGE, 1); + STUFF (DWARF2_LINE_OPCODE_BASE, 1); + + /* standard_opcode_lengths: */ + STUFF (0, 1); /* DW_LNS_copy */ + STUFF (1, 1); /* DW_LNS_advance_pc */ + STUFF (1, 1); /* DW_LNS_advance_line */ + STUFF (1, 1); /* DW_LNS_set_file */ + STUFF (1, 1); /* DW_LNS_set_column */ + STUFF (0, 1); /* DW_LNS_negate_stmt */ + STUFF (0, 1); /* DW_LNS_set_basic_block */ + STUFF (0, 1); /* DW_LNS_const_add_pc */ + STUFF (1, 1); /* DW_LNS_fixed_advance_pc */ + + subseg_set (saved_seg, saved_subseg); + + if (flag_debug) + print_stats (total_size); +} + +void +dwarf2_directive_file (int dummy) +{ + int len; + + ls.any_dwarf2_directives = 1; + + if (debug_type == DEBUG_NONE) + /* Automatically turn on DWARF2 debug info unless something else + has been selected. */ + debug_type = DEBUG_DWARF2; + + ls.current.filenum = get_absolute_expression (); + ls.current.filename = demand_copy_C_string (&len); + + demand_empty_rest_of_line (); +} + +void +dwarf2_directive_loc (int dummy) +{ + ls.any_dwarf2_directives = 1; + + ls.current.filenum = get_absolute_expression (); + SKIP_WHITESPACE (); + ls.current.line = get_absolute_expression (); + SKIP_WHITESPACE (); + ls.current.column = get_absolute_expression (); + demand_empty_rest_of_line (); + + ls.current.flags = DWARF2_FLAG_BEGIN_STMT; + +#ifndef NO_LISTING + if (listing) + listing_source_line (ls.current.line); +#endif +} + +void +dwarf2_where (struct dwarf2_line_info *line) +{ + if (ls.any_dwarf2_directives) + *line = ls.current; + else + { + char *filename; + + as_where (&line->filename, &line->line); + line->filenum = 0; + line->column = 0; + line->flags = DWARF2_FLAG_BEGIN_STMT; + } +} diff -urN gas-990404/gas/dwarf2dbg.h gas-990404-lia/gas/dwarf2dbg.h --- gas-990404/gas/dwarf2dbg.h Wed Dec 31 16:00:00 1969 +++ gas-990404-lia/gas/dwarf2dbg.h Sat May 8 10:27:15 1999 @@ -0,0 +1,48 @@ +#ifndef AS_DWARF2DBG_H +#define AS_DWARF2DBG_H + +#include "as.h" + +#define DWARF2_FLAG_BEGIN_STMT (1 << 0) /* beginning of statement */ +#define DWARF2_FLAG_BEGIN_BLOCK (1 << 1) /* beginning of basic block */ + +struct dwarf2_line_info + { + char *filename; + unsigned int filenum; + unsigned int line; + unsigned int column; + unsigned int flags; + }; + +/* Implements the .file FILENO "FILENAME" directive. FILENO can be 0 + to indicate that no file number has been assigned. All real file + number must be >0. */ +extern void dwarf2_directive_file (int dummy); + +/* Implements the .loc FILENO LINENO [COLUMN] directive. FILENO is + the file number, LINENO the line number and the (optional) COLUMN + the column of the source code that the following instruction + corresponds to. FILENO can be 0 to indicate that the filename + specified by the textually most recent .file directive should be + used. */ +extern void dwarf2_directive_loc (int dummy); + +/* Returns the current source information. If .file directives have + been encountered, the info for the corresponding source file is + returned. Otherwise, the info for the assembly source file is + returned. */ +extern void dwarf2_where (struct dwarf2_line_info *l); + +/* This function generates .debug_line info based on the address and + source information passed in the arguments. ADDR should be the + frag-relative offset of the instruction the information is for and + L is the source information that should be associated with that + address. */ +extern void dwarf2_gen_line_info (bfd_vma addr, struct dwarf2_line_info *l); + +/* Must be called after all other input is processed to finish up the + .debug_line section. */ +extern void dwarf2_finish (void); + +#endif /* AS_DWARF2DBG_H */ --- egcs-1.1.2/gcc/dwarf2out.c Thu Jul 30 05:52:18 1998 +++ egcs-1.1.2-lia/gcc/dwarf2out.c Fri May 7 15:04:30 1999 @@ -2450,7 +2450,9 @@ dw_loc_descr_ref)); static void print_spaces PROTO((FILE *)); static void print_die PROTO((dw_die_ref, FILE *)); +#ifndef ASM_DWARF2_LINE_DEBUG_INFO static void print_dwarf_line_table PROTO((FILE *)); +#endif static void add_sibling_attributes PROTO((dw_die_ref)); static void build_abbrev_table PROTO((dw_die_ref)); static unsigned long size_of_string PROTO((char *)); @@ -2459,8 +2461,10 @@ static int constant_size PROTO((long unsigned)); static unsigned long size_of_die PROTO((dw_die_ref)); static void calc_die_sizes PROTO((dw_die_ref)); +#ifndef ASM_DWARF2_LINE_DEBUG_INFO static unsigned long size_of_line_prolog PROTO((void)); static unsigned long size_of_line_info PROTO((void)); +#endif static unsigned long size_of_pubnames PROTO((void)); static unsigned long size_of_aranges PROTO((void)); static enum dwarf_form value_format PROTO((dw_val_ref)); @@ -2475,7 +2479,9 @@ static void output_pubnames PROTO((void)); static void add_arange PROTO((tree, dw_die_ref)); static void output_aranges PROTO((void)); +#ifndef ASM_DWARF2_LINE_DEBUG_INFO static void output_line_info PROTO((void)); +#endif static int is_body_block PROTO((tree)); static dw_die_ref base_type_die PROTO((tree)); static tree root_type PROTO((tree)); @@ -4308,6 +4321,8 @@ } } +#ifndef ASM_DWARF2_LINE_DEBUG_INFO + /* Print the contents of the source code line number correspondence table. This routine is a debugging aid only. */ @@ -4331,6 +4346,8 @@ fprintf (outfile, "\n\n"); } +#endif /* ASM_DWARF2_LINE_DEBUG_INFO */ + /* Print the information collected for a given DIE. */ void @@ -4348,7 +4365,9 @@ { print_indent = 0; print_die (comp_unit_die, stderr); +#ifndef ASM_DWARF2_LINE_DEBUG_INFO print_dwarf_line_table (stderr); +#endif } /* Traverse the DIE, and add a sibling attribute if it may have the @@ -4684,6 +4703,8 @@ next_die_offset += 1; } +#ifndef ASM_DWARF2_LINE_DEBUG_INFO + /* Return the size of the line information prolog generated for the compilation unit. */ @@ -4875,6 +4896,8 @@ return size; } +#endif /* ASM_DWARF2_LINE_DEBUG_INFO */ + /* Return the size of the .debug_pubnames table generated for the compilation unit. */ @@ -5625,6 +5648,8 @@ fputc ('\n', asm_out_file); } +#ifndef ASM_DWARF2_LINE_DEBUG_INFO + /* Output the source line number correspondence information. This information goes into the .debug_line section. @@ -6072,6 +6097,7 @@ } } } +#endif /* ASM_DWARF2_LINE_DEBUG_INFO */ /* Given a pointer to a BLOCK node return non-zero if (and only if) the node in question represents the outermost pair of curly braces (i.e. the "body @@ -9612,6 +9638,11 @@ { if (debug_info_level >= DINFO_LEVEL_NORMAL) { +#ifdef ASM_DWARF2_LINE_DEBUG_INFO + ++line_info_table_in_use; + fprintf (asm_out_file, "\t.file 0 \"%s\"; .loc 0 %u 0\n", + filename, line); +#else function_section (current_function_decl); if (DECL_SECTION_NAME (current_function_decl)) @@ -9664,6 +9695,7 @@ line_info->dw_file_num = lookup_filename (filename); line_info->dw_line_num = line; } +#endif /* !ASM_DWARF2_LINE_DEBUG_INFO */ } } @@ -9831,6 +9863,7 @@ ASM_OUTPUT_INTERNAL_LABEL (asm_out_file, BSS_END_LABEL, 0); #endif +#ifndef ASM_DWARF2_LINE_DEBUG_INFO /* Output the source line correspondence table. */ if (line_info_table_in_use > 1 || separate_line_info_table_in_use) { @@ -9848,6 +9881,12 @@ add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION); } +#else + /* line_info_table_in_use > 1 => at least one.file/.loc pair has + been generated */ + if (line_info_table_in_use > 1) + add_AT_section_offset (comp_unit_die, DW_AT_stmt_list, DEBUG_LINE_SECTION); +#endif /* ASM_DWARF2_LINE_DEBUG_INFO */ /* Output the abbreviation table. */ fputc ('\n', asm_out_file); ----- End forwarded message ----- From jsm@cygnus.com Sun May 9 14:31:00 1999 From: jsm@cygnus.com (Jason Molenda) Date: Sun, 09 May 1999 14:31:00 -0000 Subject: Quick test Message-ID: <19990509143118.A32123@cygnus.com> I saw a message go to gas2 but not get relayed to binutils; this is a test to see if that is continuing. No response necessary.