Menu
▾
▴
linuxsh-shmedia-dev — Linux kernel development for the SHmedia architecture
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(18) |
Apr
(7) |
May
(8) |
Jun
(19) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2006 |
Jan
(41) |
Feb
(41) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Benedict R. G. <ben...@su...> - 2003-05-15 16:16:03
|
hi, i am currently porting modutils-2.4.2 to sh64 Linux and have a question concerning the handling of relocations of instructions that are the destination of an shmedia branch. the problem i am having is how to determine when the relocation is to be included in an instruction that is an shmedia branch destination. if one looks at the code in dl-machine.h it calculates the value of the variable lsb, to be 1 or 0, by anding STO_SH5_ISA32 with the field st_other in the symbol structure (Elf32_Sym) being relocated and this result is then ored into the resulting value during the calculation the of relocation. --- it is a little strange that we are using the st_other field as this seems to be for symbol visibility! unfortunately unlike binutils and bfd the modutils does not use the bfd library, instead choosing to implement its own symbol structure (obj_symbol in obj.h) which does not contain a mapping to the symbol visibility. does any one have any ideas of what might be the best approach to solving this problem? ben. -- Benedict R. Gaster <ben...@su...> SuperH |
|
From: Sean M. <Sea...@su...> - 2003-05-15 11:59:30
|
Hi, There are 3 repositories in the linux-shmedia project. I am wondering if we can tidy things up a bit. The 'linux-2.4' tree is the main development tree, so no problems here. The 'linux' tree seems to be obsolete. It appears to be version 2.4.0-test4, and has not been modified for the last 11 months (last mod 24th June 2002). I propose to delete it - are there any problems or issues in doing this ? The 'linux-2.5' tree was last modified over 1 year ago (28th April 2002), and claims to be of the 2.5.11 vintage. I assume that when we want to put 2.5 for SH-5 into BitKeeper, we will start from a more recent baseline. Again, I propose to delete it - are there any problems or issues in doing this ? In summary, I propose to delete the 'linux' and 'linux-2.5' trees in linux-shmedia.bkbits.net. Does anyone know of a reason why this is a bad thing to do ? Also, now that the main arch tree has been renamed from 'shmedia' to 'sh64', what should we do about the BitKeeper project - should we rename 'linux-shmedia.bkbits.net' to 'linux-sh64.bkbits.net' ? If so, how do we do this, create a new project, clone from old, and delete old project - I assume one can not rename a project. Regards, Sean -- ------------------------------------------------------------------------ | Sean McGoogan, | E-mail: Sea...@Su... | | SuperH (UK) Ltd., | | | 2410 Aztec West, | Direct: +44 (0) 1454 465670 | | Almondsbury, | Main: +44 (0) 1454 465600 | | Bristol, BS32 4QX, U.K. | Fax: +44 (0) 1454 465601 | ------------------------------------------------------------------------ |
|
From: Steve W. <sc...@wa...> - 2003-04-17 09:53:16
|
On Wed, 16 Apr 2003, Sean McGoogan wrote: > Since the Barcelona-20030310 release was made a few bugs have > been found and corrected. SuperH has now made available a new improved > release Barcelona-20030414. Cool! One thing I forgot to ask last time we spoke... How well does this toolchain/binutils release support the 64-bit ABI? It's been a wee while since I built 64-bit NetBSD/sh5. Cheers, Steve -- Wasabi Systems Inc. - The NetBSD Company - http://www.wasabisystems.com/ |
|
From: Sean M. <Sea...@su...> - 2003-04-16 15:57:04
|
Hi, Since the Barcelona-20030310 release was made a few bugs have been found and corrected. SuperH has now made available a new improved release Barcelona-20030414. This is a release of gcc, binutils, and glibc. In addition to providing these in source form, x86-linux binaries are also provided: The tarballs are available in: ftp://ftp.uk.superh.com/pub/SuperH-GNU/Barcelona-20030414 % ls -l -r--r--r-- 1 13852237 Apr 16 16:08 binutils-src-2003-04-14-0600.tar.gz -r--r--r-- 1 16986264 Apr 16 16:08 glibc-src-2003-04-14-0600.tar.gz -r--r--r-- 1 16141720 Apr 16 16:08 sh5gcc-src-2003-04-14-0600.tar.gz -r--r--r-- 1 38101909 Apr 16 16:09 x86Linux-2003-04-14-0600.tar.gz % md5sum * 2711293b76287362481075867455e7c1 binutils-src-2003-04-14-0600.tar.gz 45a4ac9fcb6e837765733d671804da09 glibc-src-2003-04-14-0600.tar.gz eb48e45aea5eaa356e6cf6736e0ec60b sh5gcc-src-2003-04-14-0600.tar.gz 30e6c13d5ccbb10bce5a910939a35b6d x86Linux-2003-04-14-0600.tar.gz The sources for the above toolchain have been built on a RedHat 7.2 x86 based system, and this cross-toolchain, has been used to build the native toolchain, which has has natively built components such as make, perl, vim, etc as well as the kernel itself for SH-5 Linux. If anyone finds any problems with toolchain, then please let me know. Regards, Sean -- ------------------------------------------------------------------------ | Sean McGoogan, | E-mail: Sea...@Su... | | SuperH (UK) Ltd., | | | 2410 Aztec West, | Direct: +44 (0) 1454 465670 | | Almondsbury, | Main: +44 (0) 1454 465600 | | Bristol, BS32 4QX, U.K. | Fax: +44 (0) 1454 465601 | ------------------------------------------------------------------------ |
|
From: Thomas,Stephen <ste...@su...> - 2003-04-14 16:05:53
|
Hi Daniel, Thanks for your reply. What you suggest does appear to work, but I had = to do: gdb -c core file prog Using 'gdb -e prog -c core' (as suggested in the man page) doesn't work, = the file prog just gets ignored. But I think the core file ought to be correct if possible. Getting gdb = to generate the correct e_flags proved to be easy - they can be set in = the elf_backend_final_write_processing routine in the appropriate = elf<arch>.c. The kernel mod is also easy, it just means modifying = generic code. Thanks, Steve Thomas SuperH (UK) Ltd. -----Original Message----- From: Daniel Jacobowitz [mailto:dr...@fa...]=20 Sent: 14 April 2003 15:21 To: kaz Kojima Cc: Thomas,Stephen; McGoogan,Sean; = lin...@li...; lin...@m1...; = lin...@li... Subject: Re: [linux-sh:02691] Re: Use of e_flags field in ELF header On Mon, Apr 14, 2003 at 11:12:47PM +0900, kaz Kojima wrote: > Hi, >=20 > "Thomas,Stephen" <ste...@su...> wrote: > >Apparently, the e_flags field of the ELF Header structure in ELF=20 > >files is used by SH architectures to indicate the CPU type. The lower = > >5 bits have the following meaning: > > > > 0 =3D unknown CPU type > > 1 =3D SH1 > > 2 =3D SH2 > > 3 =3D SH3 > > 5 =3D SH3 with DSP > > 8 =3D SH3E > > 9 =3D SH4 > > 10 =3D SH5 > > > >The e_flags field is designed to hold architecture specific info, but = > >other architectures don't appear to use it in quite the same way,=20 > >i.e. to indicate different CPU types. > > > >Does anybody know why SH uses e_flags in this way? >=20 > I don't know why SH does so, but MIPS uses the upper 4 bits of e_flags = > to encode ISA. Perhaps there might be another examples. >=20 > >The problem I have is in generating & interpreting core files. When=20 > >the kernel (V2.4)generates an ELF core dump, it just sets e_flags to=20 > >0 (hard coded constant) & dumps it. So to get it to generate a valid=20 > >SH5 core dump, I need to modify generic code. There are similar=20 > >problems with the gdb 'gcore' command. >=20 > Your modification seems the right thing to do. Why is this an issue? If the core dump is marked "unknown", then the = ISA should be taken from the executable during a GDB session, and it = should do the right thing. --=20 Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer |
|
From: Daniel J. <dr...@fa...> - 2003-04-14 14:22:20
|
On Mon, Apr 14, 2003 at 11:12:47PM +0900, kaz Kojima wrote: > Hi, > > "Thomas,Stephen" <ste...@su...> wrote: > >Apparently, the e_flags field of the ELF Header structure in ELF files > >is used by SH architectures to indicate the CPU type. The lower 5 bits > > have the following meaning: > > > > 0 = unknown CPU type > > 1 = SH1 > > 2 = SH2 > > 3 = SH3 > > 5 = SH3 with DSP > > 8 = SH3E > > 9 = SH4 > > 10 = SH5 > > > >The e_flags field is designed to hold architecture specific info, but > >other architectures don't appear to use it in quite the same way, i.e. > >to indicate different CPU types. > > > >Does anybody know why SH uses e_flags in this way? > > I don't know why SH does so, but MIPS uses the upper 4 bits of e_flags > to encode ISA. Perhaps there might be another examples. > > >The problem I have is in generating & interpreting core files. When > >the kernel (V2.4)generates an ELF core dump, it just sets e_flags to 0 > >(hard coded constant) & dumps it. So to get it to generate a valid SH5 > >core dump, I need to modify generic code. There are similar problems > >with the gdb 'gcore' command. > > Your modification seems the right thing to do. Why is this an issue? If the core dump is marked "unknown", then the ISA should be taken from the executable during a GDB session, and it should do the right thing. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer |
|
From: kaz K. <kk...@rr...> - 2003-04-14 14:08:05
|
Hi, "Thomas,Stephen" <ste...@su...> wrote: >Apparently, the e_flags field of the ELF Header structure in ELF files >is used by SH architectures to indicate the CPU type. The lower 5 bits > have the following meaning: > > 0 = unknown CPU type > 1 = SH1 > 2 = SH2 > 3 = SH3 > 5 = SH3 with DSP > 8 = SH3E > 9 = SH4 > 10 = SH5 > >The e_flags field is designed to hold architecture specific info, but >other architectures don't appear to use it in quite the same way, i.e. >to indicate different CPU types. > >Does anybody know why SH uses e_flags in this way? I don't know why SH does so, but MIPS uses the upper 4 bits of e_flags to encode ISA. Perhaps there might be another examples. >The problem I have is in generating & interpreting core files. When >the kernel (V2.4)generates an ELF core dump, it just sets e_flags to 0 >(hard coded constant) & dumps it. So to get it to generate a valid SH5 >core dump, I need to modify generic code. There are similar problems >with the gdb 'gcore' command. Your modification seems the right thing to do. Regards, kaz |
|
From: Thomas,Stephen <ste...@su...> - 2003-04-14 07:58:55
|
Apparently, the e_flags field of the ELF Header structure in ELF files =
is used by SH architectures to indicate the CPU type. The lower 5 bits =
have the following meaning:
0 =3D unknown CPU type
1 =3D SH1
2 =3D SH2
3 =3D SH3
5 =3D SH3 with DSP
8 =3D SH3E
9 =3D SH4
10 =3D SH5
The e_flags field is designed to hold architecture specific info, but =
other architectures don't appear to use it in quite the same way, i.e. =
to indicate different CPU types.
Does anybody know why SH uses e_flags in this way?
The problem I have is in generating & interpreting core files. When the =
kernel (V2.4)generates an ELF core dump, it just sets e_flags to 0 (hard =
coded constant) & dumps it. So to get it to generate a valid SH5 core =
dump, I need to modify generic code. There are similar problems with the =
gdb 'gcore' command.
Steve Thomas
SuperH (UK) Ltd
|
|
From: <Jar...@cm...> - 2003-04-02 10:33:10
|
Hi, Why to rebuild Barcelona? Because I didn't find the Barcelona binaries = on the ftp.uk.superh.com. There is some file /pub/x86Linux.tar.gz, but it doesn't look like the binaries for SH5. Jaromir. -----Original Message----- From: Andrew Stubbs [mailto:and...@su...]=20 Sent: Thursday, March 27, 2003 7:46 PM To: Jarom=EDr Brambor Cc: lin...@li... Subject: RE: [linuxsh-shmedia-dev] How to build Barcelona-20030310 Why do you want to rebuild barcelona? Did you not download the binaries? = I suppose there may be many reasons for this. The target we use for all the tools is sh64-superh-linux-gnu. I haven't tested sh64-linux so I can't say that it works. Just 'sh' is definitely wrong as that would be SH1-4, but not 5. gcc is configured with --target=3D... --prefix=3D... = --with-headers=3D... --with-libs=3D... --enable-languages=3D... --without-newlib = --disable-shared --disable-multilib --disable-nls The binary barcelona gcc will actually tell you what it was configured = with if you use the -v option. The --with-headers and --with-libs should point at an installation of = glibc. These are always required for a cross compiler (for the target = libraries), but if you do not have this then you can omit them and NOT build c++. = Then when you have a C cross compiler use that to build glibc and then = rebuild the compiler with the c++ afterwards. The c++ doesn't work very well = anyway. I'll assume you know how to build glibc till you say otherwise. HTH Andrew On Thu, 2003-03-27 at 13:43, Jarom=EDr Brambor wrote: > Thanks, > I never built any gcc compiler, so I don't know what to do exactly.=20 > Probably it should be there more parameters in config (some link to=20 > something).... But I don't know. >=20 > I built binutils and it seems to be ok. > Configure for binutils: > --target=3Dsh64-linux > --prefix=3D/usr/local/sh5 >=20 > After that, I tried to configure gcc (passed ok), but fails on gcc=20 > compilation (only make, not "make bootstrap"). Compiling logged as=20 > root (should not be a problem with the rights). >=20 > Configure for gcc: > --target=3Dsh64-linux (I tried also only --target=3Dsh, but it is the=20 > same) --prefix=3D/usr/local/sh5 (the same as for binutils)=20 > --enable-languages=3Dc,c++ maybe it fails some other parameter... >=20 > what stage it fails? > in compiling ...gcc/unwind-dw2.c with warnings in its include files=20 > (imlpicit declarations)and (probably because of this) also to some=20 > parse error. for all see the attachement. The end is like this: >=20 > ... > "In function 'uw_install_context_1'" > "syntax error before "once_registers"" > "imlicit declaration of function '__gthread_once'" "'once_regsizes'=20 > undeclared (first use in this function)" "imlicit declaration of=20 > function 'memcpy'" and after that > make[2] *** [libgcc/./unwind-dw2.o] Error 1 > make[2]Leaving directory '....../gcc/gcc' > make[1] *** [stmp-multilib] Error 2 > make[1]Leaving directory '....../gcc/gcc' > make *** [all-gcc] Error 2 >=20 >=20 > Do you have any idea? > Thank you, > Jaromir >=20 >=20 > -----Original Message----- > From: Andrew Stubbs [mailto:and...@su...] > Sent: Thursday, March 27, 2003 1:04 PM > To: Jarom=EDr Brambor > Subject: Re: [linuxsh-shmedia-dev] How to build Barcelona-20030310 >=20 >=20 > I could spend ages finding out exactly what all the steps are, but it=20 > would be easier if you could give some idea what your problem is. >=20 > Have you built binutils ok? > What configure command are you using? > At what stage is the build failing? >=20 > On Thu, 2003-03-27 at 10:11, Jarom=EDr Brambor wrote: > > Hi, > > I'm trying to build SH5 cross-compiler on x86Linux from the > > Barcelona-20030310, but I have some problems, so I think I'm doinng=20 > > something wrong. > >=20 > > Could anyone provide little list of the necessery steps I should do > > for successful build? > >=20 > > Thanks (very much for any idea). > >=20 > > Jaromir > >=20 > >=20 > > --------------------------------- > > Jaromir Brambor > > Centre de Morphologie Mathematique > > Ecole des Mines de Paris > > 35, Rue Saint Honore, > > 77300 Fontainebleau, France > > email: br...@cm... > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > _______________________________________________ > > Linuxsh-shmedia-dev mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsh-shmedia-dev --=20 ------------------------------------------------------------------------ | Andrew Stubbs, | E-mail: And...@su... | | SuperH (UK) Ltd., | or st...@su... | | 2410 Aztec West, | | | Almondsbury, | Tel: +44 (0)1454 465671 | | Bristol, BS32 4QX, U.K. | Fax: +44 (0)1454 465601 | ------------------------------------------------------------------------ |
|
From: kaz K. <kk...@rr...> - 2003-03-28 21:38:15
|
Joern Rennecke <joe...@su...> wrote: > No, the bug has never been in the fsf compiler in the first place, but for > the wrong reasons. The generic code plays fast and loose with subregs > if you let it, which can result in incorrect no-op truncations from 64 > to 32 bits - the ABI requires a sign extension. We have fixed this in > our compiler version, but in the end we had to disable the base register > + index register addressing mode. There is a plan how to fix the problem > while still allowing this addressing mode, but it uses a completely > different approach, and it will require some significant amount of work > to implement. Ah, I understand. Thanks for the clarification. Regards, kaz |
|
From: Sean M. <Sea...@su...> - 2003-03-28 16:58:25
|
The code in movsi_const looked wrong. A tested patch is now attached.
--- src/gcc/config/sh/sh.md@@/main/SH5GCC-CVS20020529.1800-int/renneckej-pic-030324/0 Mon Mar 24 15:50:32 2003
+++ src/gcc/config/sh/sh.md Mon Mar 24 16:35:21 2003
@@ -3651,11 +3651,20 @@
if (GET_CODE (operands[1]) == LABEL_REF
&& GET_CODE (XEXP (operands[1], 0)) == CODE_LABEL)
LABEL_NUSES (XEXP (operands[1], 0)) += 2;
- else if (GOTOFF_P (operands[1])
- && GET_CODE (XVECEXP (XEXP (operands[1], 0), 0, 0)) == LABEL_REF
- && (GET_CODE (XEXP (XVECEXP (XEXP (operands[1], 0), 0, 0), 0))
- == CODE_LABEL))
- LABEL_NUSES (XEXP (XVECEXP (XEXP (operands[1], 0), 0, 0), 0)) += 2;
+ else if (GOTOFF_P (operands[1]))
+ {
+ rtx unspec = XEXP (operands[1], 0);
+
+ if (! UNSPEC_GOTOFF_P (unspec))
+ {
+ unspec = XEXP (unspec, 0);
+ if (! UNSPEC_GOTOFF_P (unspec))
+ abort ();
+ }
+ if (GET_CODE (XVECEXP (unspec , 0, 0)) == LABEL_REF
+ && (GET_CODE (XEXP (XVECEXP (unspec, 0, 0), 0)) == CODE_LABEL))
+ LABEL_NUSES (XEXP (XVECEXP (unspec, 0, 0), 0)) += 2;
+ }
}")
(define_expand "movsi_const_16bit"
--
------------------------------------------------------------------------
| Sean McGoogan, | E-mail: Sea...@Su... |
| SuperH (UK) Ltd., | |
| 2410 Aztec West, | Direct: +44 (0) 1454 465670 |
| Almondsbury, | Main: +44 (0) 1454 465600 |
| Bristol, BS32 4QX, U.K. | Fax: +44 (0) 1454 465601 |
------------------------------------------------------------------------
|
|
From: Joern R. <joe...@su...> - 2003-03-28 14:16:48
|
kaz Kojima wrote: > > Hi, > > I've tested Steve's example with some gcc-3.4 natively built: > > stage1 3.4 CVS 20030216 (experimental) built with cross gcc -O ok > stage2 3.4 CVS 20030216 (experimental) built with stage1 gcc -O ok > stage3 3.4 CVS 20030216 (experimental) built with stage2 gcc -O2 ok > stage4 3.4 CVS 20030216 (experimental) built with stage3 gcc -O2 ok > > So it seems the problem go away in 3.4. No, the bug has never been in the fsf compiler in the first place, but for the wrong reasons. The generic code plays fast and loose with subregs if you let it, which can result in incorrect no-op truncations from 64 to 32 bits - the ABI requires a sign extension. We have fixed this in our compiler version, but in the end we had to disable the base register + index register addressing mode. There is a plan how to fix the problem while still allowing this addressing mode, but it uses a completely different approach, and it will require some significant amount of work to implement. -- -------------------------- SuperH (UK) Ltd. 2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX T:+44 1454 465658 |
|
From: kaz K. <kk...@rr...> - 2003-03-28 12:51:32
|
Hi, I've tested Steve's example with some gcc-3.4 natively built: stage1 3.4 CVS 20030216 (experimental) built with cross gcc -O ok stage2 3.4 CVS 20030216 (experimental) built with stage1 gcc -O ok stage3 3.4 CVS 20030216 (experimental) built with stage2 gcc -O2 ok stage4 3.4 CVS 20030216 (experimental) built with stage3 gcc -O2 ok So it seems the problem go away in 3.4. Regards, kaz |
|
From: Andrew S. <and...@su...> - 2003-03-27 18:40:58
|
Why do you want to rebuild barcelona? Did you not download the binaries? I suppose there may be many reasons for this. The target we use for all the tools is sh64-superh-linux-gnu. I haven't tested sh64-linux so I can't say that it works. Just 'sh' is definitely wrong as that would be SH1-4, but not 5. gcc is configured with --target=3D... --prefix=3D... --with-headers=3D... --with-libs=3D... --enable-languages=3D... --without-newlib --disable-sha= red --disable-multilib --disable-nls The binary barcelona gcc will actually tell you what it was configured with if you use the -v option. The --with-headers and --with-libs should point at an installation of glibc. These are always required for a cross compiler (for the target libraries), but if you do not have this then you can omit them and NOT build c++. Then when you have a C cross compiler use that to build glibc and then rebuild the compiler with the c++ afterwards. The c++ doesn't work very well anyway. I'll assume you know how to build glibc till you say otherwise. HTH Andrew On Thu, 2003-03-27 at 13:43, Jarom=EDr Brambor wrote: > Thanks, > I never built any gcc compiler, so I don't know what to do exactly. Pro= bably > it should be there more parameters in config (some link to something)..= .. > But I don't know. >=20 > I built binutils and it seems to be ok. > Configure for binutils: > --target=3Dsh64-linux > --prefix=3D/usr/local/sh5 >=20 > After that, I tried to configure gcc (passed ok), but fails on gcc > compilation (only make, not "make bootstrap"). Compiling logged as root > (should not be a problem with the rights). >=20 > Configure for gcc: > --target=3Dsh64-linux (I tried also only --target=3Dsh, but it is the s= ame) > --prefix=3D/usr/local/sh5 (the same as for binutils) > --enable-languages=3Dc,c++ > maybe it fails some other parameter... >=20 > what stage it fails? > in compiling ...gcc/unwind-dw2.c with warnings in its include files > (imlpicit declarations)and (probably because of this) also to some pars= e > error. > for all see the attachement. The end is like this: >=20 > ... > "In function 'uw_install_context_1'" > "syntax error before "once_registers"" > "imlicit declaration of function '__gthread_once'" > "'once_regsizes' undeclared (first use in this function)" > "imlicit declaration of function 'memcpy'" > and after that > make[2] *** [libgcc/./unwind-dw2.o] Error 1 > make[2]Leaving directory '....../gcc/gcc' > make[1] *** [stmp-multilib] Error 2 > make[1]Leaving directory '....../gcc/gcc' > make *** [all-gcc] Error 2 >=20 >=20 > Do you have any idea? > Thank you, > Jaromir >=20 >=20 > -----Original Message----- > From: Andrew Stubbs [mailto:and...@su...]=20 > Sent: Thursday, March 27, 2003 1:04 PM > To: Jarom=EDr Brambor > Subject: Re: [linuxsh-shmedia-dev] How to build Barcelona-20030310 >=20 >=20 > I could spend ages finding out exactly what all the steps are, but it w= ould > be easier if you could give some idea what your problem is. >=20 > Have you built binutils ok? > What configure command are you using? > At what stage is the build failing? >=20 > On Thu, 2003-03-27 at 10:11, Jarom=EDr Brambor wrote: > > Hi, > > I'm trying to build SH5 cross-compiler on x86Linux from the=20 > > Barcelona-20030310, but I have some problems, so I think I'm doinng=20 > > something wrong. > >=20 > > Could anyone provide little list of the necessery steps I should do=20 > > for successful build? > >=20 > > Thanks (very much for any idea). > >=20 > > Jaromir > >=20 > >=20 > > --------------------------------- > > Jaromir Brambor > > Centre de Morphologie Mathematique > > Ecole des Mines de Paris > > 35, Rue Saint Honore, > > 77300 Fontainebleau, France > > email: br...@cm... > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > _______________________________________________ > > Linuxsh-shmedia-dev mailing list=20 > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsh-shmedia-dev --=20 ------------------------------------------------------------------------ | Andrew Stubbs, | E-mail: And...@su... | | SuperH (UK) Ltd., | or st...@su... | | 2410 Aztec West, | | | Almondsbury, | Tel: +44 (0)1454 465671 | | Bristol, BS32 4QX, U.K. | Fax: +44 (0)1454 465601 | ------------------------------------------------------------------------ |
|
From: <Jar...@cm...> - 2003-03-27 11:37:10
|
Hi, I'm trying to build SH5 cross-compiler on x86Linux from the Barcelona-20030310, but I have some problems, so I think I'm doinng something wrong. Could anyone provide little list of the necessery steps I should do for successful build? Thanks (very much for any idea). Jaromir --------------------------------- Jaromir Brambor Centre de Morphologie Mathematique Ecole des Mines de Paris 35, Rue Saint Honore, 77300 Fontainebleau, France email: br...@cm... |
|
From: kaz K. <kk...@rr...> - 2003-03-24 22:46:02
|
Hi Sean, Sean McGoogan <Sea...@su...> wrote: > My suspicion is that a hard-to-provoke code-generation bug > has been introduced a few months ago, and it only when complex native > applications like compilers are run does it present itself. We are trying > to regress our code-base and see if we can pin-point when this happened. It seems very likely to me. Such kind of gcc bug is often the result of wrongly optimized code. Building the last stage of native gcc with -O0 or -O1 would be help to see what is going on. > I would be interested to know if Kaz-san has tried this example > using a native gcc under SH-5 Linux, rather than the cross gcc. Kaz-san, > can you please let me know ? I didn't make a complete native environment yet. I'm trying to build it now. I'll look this example closely when I get a native compiler. Regards, kaz |
|
From: Sean M. <Sea...@su...> - 2003-03-24 16:44:14
|
Steve, I can confirm that SuperH has been able to reproduce your results using the toolchain from the SuperH ftp site, on SH-5 Linux. It is most interesting that the example code you provided is compiled correctly on the cross toolchain, yet SEGVs on the native toolchain - despite the fact that both toolchains are compiled from the same source code files. Even more bizarre is that our native toolchain has successfully built several large packages, and even natively built the SH-5 Linux kernel itself. We have built the native compiler statically, but this does not noticeably affect the behaviour. My suspicion is that a hard-to-provoke code-generation bug has been introduced a few months ago, and it only when complex native applications like compilers are run does it present itself. We are trying to regress our code-base and see if we can pin-point when this happened. I would be interested to know if Kaz-san has tried this example using a native gcc under SH-5 Linux, rather than the cross gcc. Kaz-san, can you please let me know ? Regards, Sean -- ------------------------------------------------------------------------ | Sean McGoogan, | E-mail: Sea...@Su... | | SuperH (UK) Ltd., | | | 2410 Aztec West, | Direct: +44 (0) 1454 465670 | | Almondsbury, | Main: +44 (0) 1454 465600 | | Bristol, BS32 4QX, U.K. | Fax: +44 (0) 1454 465601 | ------------------------------------------------------------------------ |
|
From: kaz K. <kk...@rr...> - 2003-03-24 14:55:27
|
Hi Steve, stephen clarke <ste...@st...> wrote: > kk...@rr... wrote: >> I've tested your testcase with my cross compilers >> GCC: (GNU) 2.97-sh5-010522 >> GCC: (GNU) 3.4 20021221 (experimental) >> and found no segfaults. I didn't it for the latest Barcelona toolchain >> yet because I couldn't access ftp.uk.superh.com. > > IIRC, netbsd/sh5 uses the 64-bit ABI ... did you test using the netbsd > configuration or the appropriate 64-bit ABI option? I ignored it and do it just now. The testcase can be compiled successfully with the above cross compilers even when adding -m5-64media. > Even if gcc is okay, I suspect binutils may be a problem, because I don't > think support for 64-bit SH-5 shared libraries ever got added to bfd. Ah, I see. Regards, kaz |
|
From: Steve W. <sc...@ne...> - 2003-03-24 14:11:45
|
On Mon, 24 Mar 2003, stephen clarke wrote: > IIRC, netbsd/sh5 uses the 64-bit ABI ... did you test using the netbsd > configuration or the appropriate 64-bit ABI option? NetBSD/sh5 can use either ABI (at least, the 64-bit ABI worked last time I tried it using some version of gcc-current) for both userland and kernel. By default, it uses the 32-bit ABI, if only because the 64-bit ABI offers no advantage on current silicon. The PIC bug I described earlier occurs with the 32-bit ABI. Cheers, Steve |
|
From: stephen c. <ste...@st...> - 2003-03-24 13:50:37
|
Hi Kaz, kk...@rr... wrote: > > Steve Woodford <sc...@ne...> wrote: > > At this point, I have it running natively under NetBSD/sh5 and have been > > trying to get shared libraries working (don't ask; they're needed for > > something else). In the course of this, I found a PIC bug. This may or > > may not be a problem for a cross-sh5 compiler from the same sources; I > > went straight in at the deep end and build it natively (bootstrapped using > > an earlier native sh5 toolchain, before self-hosting it). Someone else can > > verify if the cross compiler is similarly afflicted. > > I've tested your testcase with my cross compilers > GCC: (GNU) 2.97-sh5-010522 > GCC: (GNU) 3.4 20021221 (experimental) > and found no segfaults. I didn't it for the latest Barcelona toolchain > yet because I couldn't access ftp.uk.superh.com. IIRC, netbsd/sh5 uses the 64-bit ABI ... did you test using the netbsd configuration or the appropriate 64-bit ABI option? Even if gcc is okay, I suspect binutils may be a problem, because I don't think support for 64-bit SH-5 shared libraries ever got added to bfd. Steve. |
|
From: kaz K. <kk...@rr...> - 2003-03-24 12:02:38
|
Hi Boyd, "Boyd Moffat" <boy...@su...> wrote: > Use the IP address: 193.128.105.171 > I've asked IT to investigate the problem. It works fine! Thanks a lot. Regards, kaz |
|
From: Boyd M. <boy...@su...> - 2003-03-24 11:44:08
|
Kaz, Use the IP address: 193.128.105.171 I've asked IT to investigate the problem. Regards Boyd > -----Original Message----- > From: kaz Kojima [mailto:kk...@rr...] > Sent: 24 March 2003 11:43 > To: boy...@su... > Cc: lin...@li... > Subject: Re: SH5 gcc bug > > > Hi, > > "Boyd Moffat" <boy...@su...> wrote: > > Are you having problems accessing ftp.uk.superh.com? > > If so let me know what problems you are having. > > Yes, I've tried 3 paths but all of them couldn't establish > tcp connection. A report of traceroute on one path says that > the last (27th) hop found is superh01-gw.pipex.net. > > Regards, > kaz > |
|
From: kaz K. <kk...@rr...> - 2003-03-24 11:36:56
|
Hi, "Boyd Moffat" <boy...@su...> wrote: > Are you having problems accessing ftp.uk.superh.com? > If so let me know what problems you are having. Yes, I've tried 3 paths but all of them couldn't establish tcp connection. A report of traceroute on one path says that the last (27th) hop found is superh01-gw.pipex.net. Regards, kaz |
|
From: Boyd M. <boy...@su...> - 2003-03-24 10:13:55
|
Kaz, Are you having problems accessing ftp.uk.superh.com? If so let me know what problems you are having. Regards Boyd > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...] On > Behalf Of kaz Kojima > Sent: 24 March 2003 00:08 > To: lin...@li... > Subject: [linuxsh-shmedia-dev] Re: SH5 gcc bug > > > Hi, > > Steve Woodford <sc...@ne...> wrote: > > At this point, I have it running natively under NetBSD/sh5 > and have been > > trying to get shared libraries working (don't ask; they're > needed for > > something else). In the course of this, I found a PIC bug. > This may or > > may not be a problem for a cross-sh5 compiler from the same > sources; I > > went straight in at the deep end and build it natively > (bootstrapped using > > an earlier native sh5 toolchain, before self-hosting it). > Someone else can > > verify if the cross compiler is similarly afflicted. > > I've tested your testcase with my cross compilers > GCC: (GNU) 2.97-sh5-010522 > GCC: (GNU) 3.4 20021221 (experimental) > and found no segfaults. I didn't it for the latest Barcelona toolchain > yet because I couldn't access ftp.uk.superh.com. > > Regards, > kaz > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Linuxsh-shmedia-dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsh-shmedia-dev > |
|
From: kaz K. <kk...@rr...> - 2003-03-24 00:01:29
|
Hi, Steve Woodford <sc...@ne...> wrote: > At this point, I have it running natively under NetBSD/sh5 and have been > trying to get shared libraries working (don't ask; they're needed for > something else). In the course of this, I found a PIC bug. This may or > may not be a problem for a cross-sh5 compiler from the same sources; I > went straight in at the deep end and build it natively (bootstrapped using > an earlier native sh5 toolchain, before self-hosting it). Someone else can > verify if the cross compiler is similarly afflicted. I've tested your testcase with my cross compilers GCC: (GNU) 2.97-sh5-010522 GCC: (GNU) 3.4 20021221 (experimental) and found no segfaults. I didn't it for the latest Barcelona toolchain yet because I couldn't access ftp.uk.superh.com. Regards, kaz |
1 message has been excluded from this view by a project administrator.
