Debian for SuperH bootstrapping
YAEGASHI Takeshi
Matt Taggart wrote:
> > As the recent discussions in SuperH lists, we should have four
> > different architectures for SuperH, namely sh3, sh4, sh3eb, sh4eb.
> > With this scheme NIIBE Yutaka has maintained the newer deb set seen at
> > ftp://ftp.m17n.org/pub/super-h/testing/debian-011210/.
>
> Is there a large demand for the eb ones? I think sh3 and sh4 should be enough.
I agree, and suppose the project should decide it on the demands, for
which archs they should allocate space in Debian's master repository.
But it's good if we would have tools capable of managing all possible
architectures.
> I still haven't seen a good explaination why sh3/4 need to be separate. I read
> that the ABIs were slightly different but I think I heard somewhere that gcc
> could be made to generate code that works on both. Can someone please point me
> at a good explaination?
Sorry I could not provide enough explaination. (Niibe?)
It's very difficult for the runtime to handle this kind of ABI
incompatibility; and it's not recommendable to redefine the ABI
because it was defined by Hitachi and has been used by many other
compilers and tools (not GNU) for a long time.
> I recenty bought a Dreamcast system with the intent of playing with this
> stuff. I would like to see this issue resolved quickly.
Exactly.
--
YAEGASHI Takeshi <t...@keshi.org> <tak...@yaegashi.jp> <yaeg...@dodes.org>
--
To UNSUBSCRIBE, email to debian-dp...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
NIIBE Yutaka
> I still haven't seen a good explaination why sh3/4 need to be separate. I read
> that the ABIs were slightly different but I think I heard somewhere that gcc
> could be made to generate code that works on both. Can someone please point me
> at a good explaination?
It is complicated because there're many SH variants (it's the nature
of embedded system, you know).
Among various variants of SuperH, GNU/Linux (only) supports following
processors (you can check linux/arch/sh/config.in):
SH-3:
SH-7707
SH-7708
SH-7709, SH-7709A, SH-7709S
SH-4:
SH-7750, SH-7750S
SH-7751
ST40STB1
Note that we don't support SH-1, SH-2, SH-DSP series, and SH-7718
(SH-3 with single precision FPU) which is obsolete. There is SH-7729
(SH-3 with DSP), it could be used as SH7709.
GCC for GNU/Linux on SuperH supports SH-3 and SH-4. ABI is different
in three areas:
Floating point arithmetic
Calling convention (of structures on register)
Instructions which can be placed at jump slot
Major difference of SH-3 binary and SH-4 is for floating point
arithmetic. SH-3 doesn't have FPU, while SH-4 has. GCC for SH-3
generates library call for floating point arithmetic, while one for
SH-3 generates machine instructions directly. This issue could be
solved if SH-3 kernel would supports FPU emulation, but people using
SH-3 don't want to go that direction, because it slows down the
performance. Here, using SH-3 wants SH-3 ABI.
Calling convention is different (it's defined by Hitachi), perhaps for
performance reason. Hence, we cannot mix .o for SH-3 and .o for SH-4,
we need to distinguish.
At jump slot, there is constraint which instruction is OK or not.
This is different between SH-3 and SH-4. For this, we cannot say
SH-4 is upper compatible of SH-3. We can build the binary which
runs on SH-3 but not on SH-4.
Besides, people using SH-4 want to use SH-4 ABI.
--
Matt Taggart
NIIBE Yutaka writes...
[snip]
> Major difference of SH-3 binary and SH-4 is for floating point
> arithmetic. SH-3 doesn't have FPU, while SH-4 has. GCC for SH-3
> generates library call for floating point arithmetic, while one for
> SH-3 generates machine instructions directly. This issue could be
^
I assume you meant 4 here.
> solved if SH-3 kernel would supports FPU emulation, but people using
> SH-3 don't want to go that direction, because it slows down the
> performance. Here, using SH-3 wants SH-3 ABI.
OK, that makes sense.
[snip]
>
> Besides, people using SH-4 want to use SH-4 ABI.
I would prefer this as well for my Dreamcast.
What do you think about the big endian targets? Is there demand for those? I
think the Debian ftp-masters will push back on creating 4 new architectures,
but sh3 and sh4 seem to make sense.
Thanks for the explaination,
--
Matt Taggart
tag...@debian.org
NIIBE Yutaka
> What do you think about the big endian targets? Is there demand for those? I
> think the Debian ftp-masters will push back on creating 4 new architectures,
> but sh3 and sh4 seem to make sense.
IMO, there is _not_ much demand for big endian. I mean, while it
makes sense to let dpkg (or other tools) sh3eb, sh4eb enabled, I don't
think there is actual users for big endian system. The evaluation
boards has setting of endian-ness, that's true, but I don't know any
real products with big endian. HP, SEGA, Hitachi, and Compaq, all
products are little endian.
Here's a additional explanation.
SuperH series (SH in short) started with SH-1 series. For SH-1 and
SH-2, its major usage was big endian.
SH-3 came, its customer is Microsoft (WindowsCE). SH-4 came, its
customer is SEGA (Dreamcast). From SH-3 and SH-4, little endian is
majority. Actually, some feature is only available with little endian
setting (such as PCMCIA bus support).
So, some people who migrated from SH-1/SH-2 may stick big endian but
it's rare case.
Err... however, it seems for me that FPU of SH-4 is designed for big
endian system.
Well, here in oriental world, there is famous saying of Mao:
"Human being is the existence of contradiction."
Why not the processor? ;-)
--
YAEGASHI Takeshi
At Sun, 30 Dec 2001 07:21:25 +0900,
YAEGASHI Takeshi wrote:
> We need to update packaging tools such as dpkg and dpkg-cross. For
> dpkg it works for me with following patch. (NIIBE said he had another
> patch for main/enquiry.c)
Here is the updated patch including NIIBE's. It is against the CVS
dpkg (v1_9 branch).
It seems there are chages to adapt to the cross package building
environment with dpkg-cross - it might need some explaination for this
patch to be adopted.
BTW, which Debian mailing list is appropriate for the discussion on
cross package building with dpkg-cross?
Index: archtable
===================================================================
RCS file: /cvs/dpkg/dpkg/archtable,v
retrieving revision 1.18.2.1
diff -u -r1.18.2.1 archtable
--- archtable 2001/05/13 21:50:59 1.18.2.1
+++ archtable 2001/12/30 11:45:21
@@ -35,13 +35,10 @@
i386-gnu0.2 hurd-i386 undefined
ia64-linux-gnu ia64 ia64
ia64-unknown-linux ia64 ia64
-sh-linux-gnu sh sh
-sheb-linux-gnu sheb sheb
-shel-linux-gnu sh sh
-sh3-linux-gnu sh sh
-sh4-linux-gnu sh sh
-sh3eb-linux-gnu sheb sheb
-sh4eb-linux-gnu sheb sheb
+sh3-linux-gnu sh3 sh3
+sh4-linux-gnu sh4 sh4
+sh3eb-linux-gnu sh3eb sh3eb
+sh4eb-linux-gnu sh4eb sh4eb
hppa-linux-gnu hppa hppa
hppa1.1-linux-gnu hppa hppa
hppa2.0-linux-gnu hppa hppa
Index: main/enquiry.c
===================================================================
RCS file: /cvs/dpkg/dpkg/main/enquiry.c,v
retrieving revision 1.43
diff -u -r1.43 enquiry.c
--- main/enquiry.c 2001/04/24 00:42:33 1.43
+++ main/enquiry.c 2001/12/30 11:45:22
@@ -682,36 +682,41 @@
ccompiler= getenv("CC");
if (!ccompiler) ccompiler= "gcc";
- varbufinit(&vb);
- m_pipe(p1);
- ccpipe= fdopen(p1[0],"r"); if (!ccpipe) ohshite(_("failed to fdopen CC pipe"));
- if (!(c1= m_fork())) {
- m_dup2(p1[1],1); close(p1[0]); close(p1[1]);
- execlp(ccompiler,ccompiler,"--print-libgcc-file-name",(char*)0);
- /* if we have a problem excuting the C compiler, we don't
- * want to fail. If there is a problem with the compiler,
- * like not being installed, or CC being set incorrectly,
- * then important problems will show up elsewhere, not in
- * dpkg. If a C compiler is not important to the reason we
- * are being called, then we should just give them the built
- * in arch.
- */
- if (printf("/usr/lib/gcc-lib/%s-none/0.0.0/libgcc.a\n",architecture) == EOF)
- werr("stdout");
- if (fflush(stdout)) werr("stdout");
- exit(0);
+ if (!strncmp(ccompiler, "gcc", 3)) {
+ varbufinit(&vb);
+ m_pipe(p1);
+ ccpipe= fdopen(p1[0],"r"); if (!ccpipe) ohshite(_("failed to fdopen CC pipe"));
+ if (!(c1= m_fork())) {
+ m_dup2(p1[1],1); close(p1[0]); close(p1[1]);
+ execlp(ccompiler,ccompiler,"--print-libgcc-file-name",(char*)0);
+ /* if we have a problem excuting the C compiler, we don't
+ * want to fail. If there is a problem with the compiler,
+ * like not being installed, or CC being set incorrectly,
+ * then important problems will show up elsewhere, not in
+ * dpkg. If a C compiler is not important to the reason we
+ * are being called, then we should just give them the built
+ * in arch.
+ */
+ if (printf("/usr/lib/gcc-lib/%s-none/0.0.0/libgcc.a\n",architecture) == EOF)
+ werr("stdout");
+ if (fflush(stdout)) werr("stdout");
+ exit(0);
+ }
+ close(p1[1]);
+ fd_vbuf_copy(fileno(ccpipe), &vb, -1, _("error reading from CC pipe"));
+ waitsubproc(c1,"gcc --print-libgcc-file-name",0);
+ if (!vb.used) badlgccfn(ccompiler,"",_("empty output"));
+ varbufaddc(&vb,0);
+ if (vb.buf[vb.used-2] != '\n') badlgccfn(ccompiler,vb.buf,_("no newline"));
+ vb.used-= 2; varbufaddc(&vb,0);
+ p= strstr(vb.buf,"/gcc-lib/");
+ if (!p) badlgccfn(ccompiler,vb.buf,_("no gcc-lib component"));
+ p+= 9;
+ q= strchr(p,'/'); if (!q) badlgccfn(ccompiler,vb.buf,_("no slash after gcc-lib"));
+ } else {
+ p= ccompiler;
+ q= strrchr(p, '-');
}
- close(p1[1]);
- fd_vbuf_copy(fileno(ccpipe), &vb, -1, _("error reading from CC pipe"));
- waitsubproc(c1,"gcc --print-libgcc-file-name",0);
- if (!vb.used) badlgccfn(ccompiler,"",_("empty output"));
- varbufaddc(&vb,0);
- if (vb.buf[vb.used-2] != '\n') badlgccfn(ccompiler,vb.buf,_("no newline"));
- vb.used-= 2; varbufaddc(&vb,0);
- p= strstr(vb.buf,"/gcc-lib/");
- if (!p) badlgccfn(ccompiler,vb.buf,_("no gcc-lib component"));
- p+= 9;
- q= strchr(p,'/'); if (!q) badlgccfn(ccompiler,vb.buf,_("no slash after gcc-lib"));
ll= q-p;
for (archp=archtable;
archp->from && strncmp(archp->from,p,ll);
Index: scripts/dpkg-architecture.pl
===================================================================
RCS file: /cvs/dpkg/dpkg/scripts/dpkg-architecture.pl,v
retrieving revision 1.19.2.3
diff -u -r1.19.2.3 dpkg-architecture.pl
--- scripts/dpkg-architecture.pl 2001/06/20 00:39:27 1.19.2.3
+++ scripts/dpkg-architecture.pl 2001/12/30 11:45:23
@@ -56,8 +56,10 @@
'powerpc', 'powerpc-linux',
'mips', 'mips-linux',
'mipsel', 'mipsel-linux',
- 'sh', 'sh-linux',
- 'sheb', 'sheb-linux',
+ 'sh3', 'sh3-linux',
+ 'sh3eb', 'sh3eb-linux',
+ 'sh4', 'sh4-linux',
+ 'sh4eb', 'sh4eb-linux',
'hppa', 'hppa-linux',
'hurd-i386', 'i386-gnu',
's390', 's390-linux',
@@ -94,7 +96,6 @@
s/(?:i386|i486|i586|i686|pentium)(.*linux)/i386$1/;
s/ppc/powerpc/;
- s/sh[34]/sh/;
return $_;
}
@@ -125,17 +126,21 @@
$deb_build_gnu_system =~ s/^.*-//;
# Default host: Current gcc.
-$gcc = `\${CC:-gcc} --print-libgcc-file-name`;
-if ($?>>8) {
- &warn("Couldn't determine gcc system type, falling back to default (native compilation)");
- $gcc = '';
+if ($ENV{'CC'} =~ m/^(.*)-gcc$/) {
+ $gcc = $1;
} else {
- $gcc =~ s!^.*gcc-lib/([^/]*)/(?:egcs-)?\d+(?:[.\da-z]*)/libgcc.*$!$1!s;
- if (defined $1 and $1 ne '') {
- $gcc = $1;
- } else {
+ $gcc = `\${CC:-gcc} --print-libgcc-file-name`;
+ if ($?>>8) {
&warn("Couldn't determine gcc system type, falling back to default (native compilation)");
$gcc = '';
+ } else {
+ $gcc =~ s!^.*gcc-lib/([^/]*)/(?:egcs-)?\d+(?:[.\da-z]*)/libgcc.*$!$1!s;
+ if (defined $1 and $1 ne '') {
+ $gcc = $1;
+ } else {
+ &warn("Couldn't determine gcc system type, falling back to default (native compilation)");
+ $gcc = '';
+ }
}
}
--
YAEGASHI Takeshi <t...@keshi.org> <tak...@yaegashi.jp> <yaeg...@dodes.org>
Wichert Akkerman
> Here is the updated patch including NIIBE's. It is against the CVS
> dpkg (v1_9 branch).
Please make a patch for the HEAD branch instead.
> It seems there are chages to adapt to the cross package building
> environment with dpkg-cross - it might need some explaination for this
> patch to be adopted.
Definitely. I would rather get rid of that bit of code and use
dpkg-architecture only.
> BTW, which Debian mailing list is appropriate for the discussion on
> cross package building with dpkg-cross?
It has no specific list, but debian-dpkg should suffice.
Wichert.
--
_________________________________________________________________
/wic...@wiggy.net This space intentionally left occupied \
| wic...@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Wichert Akkerman
> Ok. But I found some flaws trying the HEAD branch before, and which
> made me use the release one. I'll ask here about it later.
That's the reason it's not released yet :). The v1_9 branch is just
to maintain the 1.9 series of dpkg, and not where new features are
added.