matthew green | 1 Mar 11:01 2003
Picon

binutils update update


hi folks.

i've gotten new binutils working on all currently supported platforms that
build.  this means:

	sparc, sparc64, arm, mips, i386, powerpc, m68k, vax & alpha.

i have made m68000 (sun2) and sh3le/sh3be build the new bits, but due to
other issues (pthreads) they don't build at all currently so i have not
tested they work.  then again, we've probably never had a binutils updated
where 9 platforms were tested first :)  new binutils also will bring in
support for hppa & x86_64...

so, the plan is to import it real soon now (maybe my tonight even) and
merge shortly afterwards.  the tree may break for a little while...

other issues:

	- this bumps libbfd's major number, which means gdb will need to
	be recompiled.  my simple testing shows that gdb still mostly
	works (however, eg, sh3 won't), but may generate warnings due to
	using old BFD functions.  this will be fixed when ...

	- GDB update comes next.  i'm going to need help on this one as
	i'm least familiar with GDB out of all the toolchain parts...

.mrg.

(Continue reading)

Ignatios Souvatzis | 1 Mar 12:02 2003
Picon

Re: binutils update update

Hi,

On Sat, Mar 01, 2003 at 09:01:33PM +1100, matthew green wrote:
> new binutils also will bring in support for hppa

hooray!

I have an extremely bulky piece of hardware of that kind...

	-is
--

-- 
seal your e-mail: http://www.gnupg.org/

Jason R Thorpe | 1 Mar 18:17 2003

Re: binutils update update

On Sat, Mar 01, 2003 at 09:01:33PM +1100, matthew green wrote:

 > i've gotten new binutils working on all currently supported platforms that
 > build.  this means:
 > 
 > 	sparc, sparc64, arm, mips, i386, powerpc, m68k, vax & alpha.
 > 
 > i have made m68000 (sun2) and sh3le/sh3be build the new bits, but due to
 > other issues (pthreads) they don't build at all currently so i have not
 > tested they work.  then again, we've probably never had a binutils updated
 > where 9 platforms were tested first :)  new binutils also will bring in
 > support for hppa & x86_64...

Matt, thanks a ton!

 > 	- GDB update comes next.  i'm going to need help on this one as
 > 	i'm least familiar with GDB out of all the toolchain parts...

I'll chat with you offline about some outstanding GDB issues, as well.
GDB isn't quite "out-of-the-box" on all of our platforms, yet.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

toddpw | 3 Mar 09:27 2003

Re: I want to rid ugly float load/stores used only for data movement

> On Sat, Feb 22, 2003 at 06:09:13PM -0500, David Edelsohn wrote:
> 
>  > MLR> Would anyone point me in the correct direction?
>  > 
>  > 	Your intent cannot be implemented safely in GCC.  If GCC knows it
>  > has FPRs and FPRs hold 64-bit values (which they must), it will use them
>  > for 64-bit moves.  Cannot be avoided safely.
> 
> That's kind of a bummer.  I seem to recall the idea of "no-implicit-fp"
> coming up on the GCC mailing list recently, too.  The reason people want
> is to eliminate unpredictable context switch times and/or speed up context
> switching.

Yes. Check GCC's CVS and I think you will find that this is fixed.

This "implicit FP" stuff was causing trouble on VxWorks; Wind River raised
this issue with the FSF.

As I recall, the decision was to abandon this sly use of FP registers.
So, at some point, bringing in a new GCC should fix it.

BTW, Mouse: GCC already avoids this tactic on chips for which FP registers
do not hold arbitrary values (i386, m68k, to name a couple). Please, give
them _some_ credit.

--

-- 
Todd Whitesel
toddpw  <at>  toddpw.org

(Continue reading)

der Mouse | 3 Mar 09:30 2003
Picon

Re: I want to rid ugly float load/stores used only for data movement

> BTW, Mouse: GCC already avoids this tactic on chips for which FP
> registers do not hold arbitrary values (i386, m68k, to name a
> couple).  Please, give them _some_ credit.

Um, then, I guess I don't understand.  Surely it's easy enough to avoid
it on any machine, then, just by telling gcc that the FP registers work
like the i386 or m68k FP registers and can't hold arbitrary values?  I
thought someone said that it was difficult to teach gcc to not do this,
which seemed at odds with gcc already knowing how to not do this.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

toddpw | 3 Mar 09:48 2003

Re: I want to rid ugly float load/stores used only for data movement

> > BTW, Mouse: GCC already avoids this tactic on chips for which FP
> > registers do not hold arbitrary values (i386, m68k, to name a
> > couple).  Please, give them _some_ credit.
> 
> Um, then, I guess I don't understand.  Surely it's easy enough to avoid
> it on any machine, then, just by telling gcc that the FP registers work
> like the i386 or m68k FP registers and can't hold arbitrary values?  I
> thought someone said that it was difficult to teach gcc to not do this,
> which seemed at odds with gcc already knowing how to not do this.

er, sorry, I should have directed that comment at David, since it was
his misinformation that prompted your original comment.

In any case, there is definitely a problem with GCC using FP registers on
PPC to do 64-bit moves, it has definitely been dealt with in the Wind River
edition of GCC, and I am pretty sure the FSF squashed it in their GCC at
some point as well.

--

-- 
Todd Whitesel
toddpw  <at>  toddpw.org

Richard Earnshaw | 3 Mar 12:02 2003

Re: I want to rid ugly float load/stores used only for data movement

> > BTW, Mouse: GCC already avoids this tactic on chips for which FP
> > registers do not hold arbitrary values (i386, m68k, to name a
> > couple).  Please, give them _some_ credit.
> 
> Um, then, I guess I don't understand.  Surely it's easy enough to avoid
> it on any machine, then, just by telling gcc that the FP registers work
> like the i386 or m68k FP registers and can't hold arbitrary values?  I
> thought someone said that it was difficult to teach gcc to not do this,
> which seemed at odds with gcc already knowing how to not do this.

It's not necessarily that trivial.  It depends on the way the ISA works.   
In particular it can depend on how integer<->float conversion is done.

If the processor converts integers to floats by loading an integer into a 
floating-point register and then running a conversion instruction on the 
result, then gcc *has* to have rules to allow integer-values to be loaded 
into floating point registers[1].  Once you have that then the compiler 
will see that it's possible for a floating point register to hold any 
value and it can try to make use of that.

If simply transferring an integer value into a floating point register 
will cause a conversion to happen then there is no need for the compiler 
to have rules that allow arbitrary integers to be loaded into floating 
point registers.  Without the rules to load integer values into floating 
point registers then FP registers will never get used for general-purpose 
copying.

R.

[1]  Not strictly true, it is possible to not give the compiler any rules 
(Continue reading)

Tom Spindler | 4 Mar 05:13 2003

mdsetimage doesn't like the new bfd

mdsetimage doesn't seem to like the new bfd much. for whatever reason, it
looks like abfd->outsymbols contains NULL - when bfd reads in
netbsd-RESCUE_TINY, at least - and so elf_map_symbols() barfs.

FWIW, gdb whinges about these, too:
Deprecated bfd_read called at /media/src/src/gnu/dist/toolchain/gdb/dbxread.c line 2638 in elfstab_build_psymtabs
Deprecated bfd_read called at /media/src/src/gnu/dist/toolchain/gdb/dbxread.c line 976 in fill_symbuf

(gdb) run -v netbsd-RESCUE_TINY /media/src/src/distrib/i386/floppies/ramdisk-rescuetiny/obj.i386/ramdisk-rescuetiny.fs
Starting program: /usr/src/tools/mdsetimage/obj.i386/mdsetimage -v netbsd-RESCUE_TINY /media/src/src/distrib/i386/floppies/ramdisk-rescuetiny/obj.i386/ramdisk-rescuetiny.fs
got symbols from netbsd-RESCUE_TINY
mapped netbsd-RESCUE_TINY
copying image
/media/src/src/distrib/i386/floppies/ramdisk-rescuetiny/obj.i386/ramdisk-rescuetiny.fs
into netbsd-RESCUE_TINY
done copying image
exiting

Program received signal SIGSEGV, Segmentation fault.
0x80641df in elf_map_symbols (abfd=0x80ae000)
    at /media/src/src/tools/toolchain/../../gnu/dist/toolchain/bfd/elf.c:2879
2879          asymbol *sym = syms[idx];
(gdb) print syms
$1 = (asymbol **) 0x0
(gdb) bt
#0  0x80641df in elf_map_symbols (abfd=0x80ae000)
    at /media/src/src/tools/toolchain/../../gnu/dist/toolchain/bfd/elf.c:2879
#1  0x8066add in swap_out_syms (abfd=0x80ae000, sttp=0xbfbef2a4, 
    relocatable_p=0)
    at /media/src/src/tools/toolchain/../../gnu/dist/toolchain/bfd/elf.c:5211
(Continue reading)

Izumi Tsutsui | 4 Mar 15:47 2003
Picon

Re: mdsetimage doesn't like the new bfd

In article <20030304041334.GA19896 <at> babymeat.com>
dogcow <at> babymeat.com wrote:

> mdsetimage doesn't seem to like the new bfd much. for whatever reason, it
> looks like abfd->outsymbols contains NULL - when bfd reads in
> netbsd-RESCUE_TINY, at least - and so elf_map_symbols() barfs.

dbsym(8) has the same problem.

I guess there are some changes in bfd usage,
but I haven't tracked it yet.
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp

John Klos | 5 Mar 10:37 2003

macppc -current brokenness

Hi,

The import of binutils 2.13.2.1 seems to have broken some stuff in
-current. Does someone who understands the coff stuff know how to fix
this?

dependall ===> sys/arch/macppc/stand/fixcoff
/usr/src/tools/obj/tools.NetBSD-1.6P-powerpc/bin/nbhost-mkdep -a
/usr/src/sys/arch/macppc/stand/fixcoff/fixcoff.c
/usr/src/sys/arch/macppc/stand/fixcoff/nb_progname.c
cc -O  -c -o fixcoff.lo.o /usr/src/sys/arch/macppc/stand/fixcoff/fixcoff.c
In file included from /usr/src/sys/arch/macppc/stand/fixcoff/fixcoff.c:49:
/usr/src/sys/arch/macppc/stand/fixcoff/../../../../../gnu/dist/toolchain/include/coff/rs6000.h:226:
parse error before `bfd_byte'
/usr/src/sys/arch/macppc/stand/fixcoff/../../../../../gnu/dist/toolchain/include/coff/rs6000.h:226:
warning: no semicolon at end of struct or union
/usr/src/sys/arch/macppc/stand/fixcoff/../../../../../gnu/dist/toolchain/include/coff/rs6000.h:227:
warning: data definition has no type or storage class
/usr/src/sys/arch/macppc/stand/fixcoff/../../../../../gnu/dist/toolchain/include/coff/rs6000.h:228:
parse error before `l_nreloc'
...

Thanks,
John Klos
ZiaSpace Productions


Gmane