Menu
▾
▴
linuxsh-dev
|
From: Bryan R. <br...@ix...> - 2001-01-05 03:04:05
|
Hello, After a couple of months of using the older toolchain (from around 8/00) I have run into some problems that I suspect may have been addressed by the efforts since then. But after falling partially out of the loop I've lost track of toolchain/kernel development progress and have the following questions: 1. Where can I get the latest versions of gcc, binutils, glibc, etc? Is the LinuxSH CVS repository up to date, or are they only availible as tar archives on an ftp/web server? 2. Does this toolchain properly build the latest CVS kernel? Are the CVS kernel sources still the latest? 2. Are there build directions for these newer versions, similar to what exists for the old toolchain on the LinuxSH website? If not, is anyone able to supply working build instructions? 3. What is the status of the SH merge into the main, upstream gcc/glibc/binutils/kernel sources? 4. Does native GDB work correctly now? If not, what problems remain, and, if anyone is working on them, how can I assist? I would greatly appreciate it if someone could bring me up to date, so that I can track current development (as it happens) and offer my humble assistance/patches.... I look forward to working with all of you once again. Thank you! Respectfully, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Denis D. <dp...@pr...> - 2001-01-05 03:31:21
|
Hi Bryan, I have been working with the new toolchain for a couple of weeks now so I can answer some of your questions. Bryan Rittmeyer wrote: > > Hello, > > After a couple of months of using the older toolchain (from around 8/00) > I have run into some problems that I suspect may have been addressed by > the efforts since then. But after falling partially out of the loop I've > lost track of toolchain/kernel development progress and have the > following questions: > > 1. Where can I get the latest versions of gcc, binutils, glibc, etc? Is > the LinuxSH CVS repository up to date, or are they only availible as tar > archives on an ftp/web server? The CVS repository is out of date for the tool chain. You need to get a recent binutils, gcc and glibc from CVS. > > 2. Does this toolchain properly build the latest CVS kernel? Are the CVS > kernel sources still the latest? The new toolchain works with the current CVS kernel. > > 2. Are there build directions for these newer versions, similar to what > exists for the old toolchain on the LinuxSH website? If not, is anyone > able to supply working build instructions? No detailed instructions yet. I managed to pull this all together from the mailing list and the web. > > 3. What is the status of the SH merge into the main, upstream > gcc/glibc/binutils/kernel sources? Most of this is done now. gcc 2.97 has SH support built in. Latest binutils is OK but needs some patches to support shared libraries. You also need latest glibc 2.2 to handle shared libraries. > > 4. Does native GDB work correctly now? If not, what problems remain, > and, if anyone is working on them, how can I assist? I far as I can tell this works now. If you want I can send you my patches to gcc-20001120, binutils-001210 and glibc2.2? Regards, Denis |
|
From: kaz K. <kk...@rr...> - 2001-01-05 04:22:16
|
Hi, Denis Dowling <dp...@pr...> wrote: > Hi Bryan, > > I have been working with the new toolchain for a couple of weeks now so > I can answer some of your questions. Almost all were answered by Denis and Greg. I'd like to add a few comments only. Current gcc in an...@gc... has some problems. I'm fixing them, but it's not completed yet. You can get relatively stable 20001120 version and its patch from http://www.m17n.org/linux-sh/. I'm preparing a patch about relocations for binutils which will be sent to the mainstream. Meanwhile please use the local patch from Denis. It includes all my patchs which are explained in http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/temporary-README-new-toolchain. About the native gdb, it works but I found some problem. Especially a program which will be debugged should be compiled with -O0 -g, i.e. without any optimizations and unfortunately, the compilation with -O0 fails in some cases even with 20001120 version of gcc. kaz |
|
From: Bryan R. <br...@ix...> - 2001-01-07 00:14:00
|
Hello! kaz Kojima wrote: > About the native gdb, it works but I found some problem. Especially a Can you please provide me with the build commands you used to cross compile a native (sh4) gdb? I.E. What flags did you pass to configure? Did you have to modify Makefiles by hand? I am trying to build sh4 gdb on my x86 linux workstation, but the native x86 utilities keep getting used instead of the cross utilities, leading to incorrect object code. I am working with the latest GDB CVS sources, with your patch http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gdb-cvs-001102.diff.gz applied. One hunk was rejected due to some format changes, but I applied it by hand. Also, have you attempted to use gdbserver on the SH4? I am going to be debugging very large applications, which may not fit into the embedded target unless stripped of debugging symbols. gdbserver works with a stripped binary on the target and communicates with a master gdb, which has a non-stripped binary, on a workstation. Thank you! Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: kaz K. <kk...@rr...> - 2001-01-07 03:02:47
|
Bryan Rittmeyer <br...@ix...> wrote: > Can you please provide me with the build commands you used to cross > compile a native (sh4) gdb? I.E. What flags did you pass to configure? > Did you have to modify Makefiles by hand? Sorry, I've tested it only in pure native environment, i.e. configure, make and tests were done in linux-sh itself. > Also, have you attempted to use gdbserver on the SH4? I didn't try it. kaz |
|
From: Bryan R. <br...@ix...> - 2001-01-09 21:10:34
|
kaz Kojima wrote: > Sorry, I've tested it only in pure native environment, i.e. configure, > make and tests were done in linux-sh itself. Is there any way you could send me a static linked binary? I am unable to build gdb in linux-sh itself, and am having trouble with the cross compiled version that I built (using a slightly modified version of kaz Kojima's patch--I have not yet tried yours, Denis): [@(none) bin]# ./gdbtest running foo... foo:0 foo:1 foo:2 foo:3 foo:4 foo:5 foo:6 foo:7 foo:8 foo:9 running bar... bar:10 bar:9 bar:8 bar:7 bar:6 bar:5 bar:4 bar:3 bar:2 bar:1 exiting... [@(none) bin]# ./gdb gdbtest GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sh-linux-gnu"... (gdb) break bar Breakpoint 1 at 0x4004aa: file foo.c, line 31. (gdb) run Starting program: /bin/gdbtest --- my serial console freezes there, no output from gdbtest is displayed, and the breakpoint is never triggered. However I can still CTRL-Z gdb and kill it... if I run "gdb gdbtest" again it does the same thing, except gdb takes over the console and I am unable to return to the busybox shell--the only way out is a system reset. gdbtest is built -Wall -g -O0 I am using GDB 5.0 with glibc2.1.3, kernel 2.4.0, all built using the old toolchain. GDB is compiled against libtermcap.so.2 which I built from the sources in the HardHat-alike SH4 port at http://linuxsh.sourceforge.net/docs/shrpm.php3 Unless you guys have seen this problem before and know of a fix, I'm going to go ahead and try the new toolchain and GDB patch that Denis supplied, and see how that works out. I have a hunch GDB 5.0 wants a newer glibc/binutils. Thanks again, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: kaz K. <kk...@rr...> - 2001-01-10 00:00:08
|
Bryan Rittmeyer <br...@ix...> wrote: > Is there any way you could send me a static linked binary? I am unable > to build gdb in linux-sh itself, and am having trouble with the cross > compiled version that I built (using a slightly modified version of kaz > Kojima's patch--I have not yet tried yours, Denis): ok. I'll send a private mail about the static linked gdb. Anyway, the native gdb isn't tested enough and I suspect there may be bugs not only on the gdb side but also in gcc and others. kaz |
|
From: Bryan R. <br...@ix...> - 2001-01-10 00:30:23
|
kaz Kojima wrote: > Anyway, the native gdb isn't tested enough and I suspect there > may be bugs not only on the gdb side but also in gcc and others. LinuxSH definitely needs a reliable gdb... perhaps, time permitting, we can work together on getting gdb itself debugged? I think many will benefit from a solid way to debug user code on SH... also, having native gdb makes subtle compiler errors easier to find. Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: kaz K. <kk...@rr...> - 2001-01-10 01:12:37
|
Bryan Rittmeyer <br...@ix...> wrote: >> Anyway, the native gdb isn't tested enough and I suspect there >> may be bugs not only on the gdb side but also in gcc and others. > > LinuxSH definitely needs a reliable gdb... perhaps, time permitting, we > can work together on getting gdb itself debugged? > > I think many will benefit from a solid way to debug user code on SH... > also, having native gdb makes subtle compiler errors easier to find. Of course, you are right. We need it. But I think that some issues of compiler are at more fundamental level and have high priorty yet. kaz |
|
From: Bryan R. <br...@ix...> - 2001-01-10 03:54:59
|
kaz Kojima wrote: > Of course, you are right. We need it. But I think that some issues > of compiler are at more fundamental level and have high priorty yet. Yes, agreed. We first need to make sure gcc produces a correct gdb binary! Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Denis D. <dp...@pr...> - 2001-01-07 23:46:20
|
First you need to apply all of the patches in sh-gdb-patch.tar.gz to the
gdb sources.
I am using the following lines to build gdb and gdbserver.
It all builds but is not tested yet.
# Build gdb-client for cross-debugging
./configure --build i386-linux-gnu --host i386-linux-gnu --target
sh-linux-gnu
mv gdb/gdb gdb/gdb-client
make distclean
# Build gdb for native debugging
./configure --build i386-linux-gnu --host sh-linux-gnu --target
sh-linux-gnu
make
# Build gdbserver for cross-debugging
cd gdb/gdbserver
../../configure --build i386-linux-gnu --host sh-linux-gnu --target
sh-linux-gnu --prefix
make CC="sh-linux-gnu -ml -m4"
Hope this works for you. Let me know how you get on.
Regards,
Denis.
Bryan Rittmeyer wrote:
>
> Hello!
>
> kaz Kojima wrote:
>
> > About the native gdb, it works but I found some problem. Especially a
>
> Can you please provide me with the build commands you used to cross
> compile a native (sh4) gdb? I.E. What flags did you pass to configure?
> Did you have to modify Makefiles by hand?
>
> I am trying to build sh4 gdb on my x86 linux workstation, but the native
> x86 utilities keep getting used instead of the cross utilities, leading
> to incorrect object code.
>
> I am working with the latest GDB CVS sources, with your patch
> http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gdb-cvs-001102.diff.gz
> applied. One hunk was rejected due to some format changes, but I applied
> it by hand.
>
> Also, have you attempted to use gdbserver on the SH4? I am going to be
> debugging very large applications, which may not fit into the embedded
> target unless stripped of debugging symbols. gdbserver works with a
> stripped binary on the target and communicates with a master gdb, which
> has a non-stripped binary, on a workstation.
>
> Thank you!
>
> Regards,
>
> Bryan
>
> --
> Bryan Rittmeyer
> mailto:br...@ix...
> Ixia Communications
> 26601 W. Agoura Rd.
> Calabasas, CA 91302
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
|
|
From: Denis D. <dp...@pr...> - 2001-01-07 23:47:02
Attachments:
sh-gdb-patch.tar.gz
|
This time I will remember to attach the patch file. |
|
From: Bryan R. <br...@ix...> - 2001-01-05 05:04:05
|
Denis Dowling wrote:
> I have been working with the new toolchain for a couple of weeks now so
> I can answer some of your questions.
Much obliged. :)
> The CVS repository is out of date for the tool chain. You need to get a
> recent binutils, gcc and glibc from CVS.
hm. I assume the first CVS here means the LinuxSH CVS archive on
sourceforge. Your final "CVS" refers to the upstream GNU CVS servers??
> No detailed instructions yet. I managed to pull this all together from
> the mailing list and the web.
Alright, I will browse over the mailing list archive (which I just
remembered exists, apologies for not using it prior). Which web
resources did you find useful?
> If you want I can send you my patches to gcc-20001120, binutils-001210
> and glibc2.2?
That would be great. I got binutils-001005 (from m17n) to build but
-001210 looks newer.
Using binutils-001005, I am having trouble getting gcc-200001120 to
build:
---
make[2]: Entering directory
`/home/bryan/src/newtoolchain/gcc-sh-linux/sh-linux-gnu/zlib'
/bin/sh ./libtool --mode=compile
/home/bryan/src/newtoolchain/gcc-sh-linux/gcc/xgcc
-B/home/bryan/src/newtoolchain/gcc-sh-linux/gcc/
-B/usr/local/sh/sh-linux-gnu/bin/ -B/usr/local/sh/sh-linux-gnu/lib/
-isystem /usr/local/sh/sh-linux-gnu/include -DPACKAGE=\"zlib\"
-DVERSION=\"1.1.3\" -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1
-I. -I../../../gcc-sh-linux-20001120/zlib -g -O2 -c
../../../gcc-sh-linux-20001120/zlib/adler32.c
mkdir .libs
/home/bryan/src/newtoolchain/gcc-sh-linux/gcc/xgcc
-B/home/bryan/src/newtoolchain/gcc-sh-linux/gcc/
-B/usr/local/sh/sh-linux-gnu/bin/ -B/usr/local/sh/sh-linux-gnu/lib/
-isystem /usr/local/sh/sh-linux-gnu/include -DPACKAGE=\"zlib\"
-DVERSION=\"1.1.3\" -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1
-I. -I../../../gcc-sh-linux-20001120/zlib -g -O2 -c
../../../gcc-sh-linux-20001120/zlib/adler32.c -fPIC -DPIC -o
.libs/adler32.o
In file included from ../../../gcc-sh-linux-20001120/zlib/zlib.h:34,
from ../../../gcc-sh-linux-20001120/zlib/adler32.c:7:
../../../gcc-sh-linux-20001120/zlib/zconf.h:239:41: sys/types.h: No such
file or directory
../../../gcc-sh-linux-20001120/zlib/zconf.h:240:52: unistd.h: No such
file or directory
../../../gcc-sh-linux-20001120/zlib/zlib.h:757: parse error before
"gzseek"
../../../gcc-sh-linux-20001120/zlib/zlib.h:757: parse error before
"off_t"
../../../gcc-sh-linux-20001120/zlib/zlib.h:758: warning: data definition
has no type or storage class
../../../gcc-sh-linux-20001120/zlib/zlib.h:782: parse error before
"gztell"
../../../gcc-sh-linux-20001120/zlib/zlib.h:782: warning: data definition
has no type or storage class
make[2]: *** [adler32.lo] Error 1
make[2]: Leaving directory
`/home/bryan/src/newtoolchain/gcc-sh-linux/sh-linux-gnu/zlib'
make[1]: *** [all-target-zlib] Error 2
make[1]: Leaving directory `/home/bryan/src/newtoolchain/gcc-sh-linux'
make: *** [cross] Error 2
---
This is after a binutils:
configure --target=sh-linux-gnu --prefix=/usr/local/sh
make
make install
and a gcc:
configure --target=sh-linux-gnu --prefix=/usr/local/sh
make cross
(I am using separate build and source directories for both binutils and
gcc, as suggested)
I saw a couple posts from a few days (weeks?) ago about disabling the
zlib build... can you further enlighten me?
I haven't even attempted glibc2.2 yet... but I would really appreciate
any and all patches you found useful when getting this stuff up and
running.
Thanks for the (quick!) reply,
Bryan
--
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
|
|
From: Bryan R. <br...@ix...> - 2001-01-05 05:42:45
|
[I've CC'd the list so that our conversations get archived] Denis Dowling wrote: > > That would be great. I got binutils-001005 (from m17n) to build but > > -001210 looks newer. > > You need the newer binutils. I couldn't find the 001210 revision at ftp.m17n.org:/pub/super-h/testing/ Could you please e-mail it to me, or give me a URL? > OK. You need to unpack both gcc-core-20001120 and gcc-g++-20001120. You > will need a patch to configure so that it correctly handles > target=sh-linux-gnu. Also to stop zlib from building you need to do: > > LANGUAGES="c" ./configure .... Alright. Where can I snag this sh-linux-gnu target patch? BTW, I am also extremely interested in getting the C++ compiler built. Will LANGUAGES="c" prevent --enable-languages=c,c++ from working? (I'm inclined to think not... If I remember correctly, these directives do wholly separate things) > loop alone is about 6 hours of CPU time :-( As of last night I had X up > and running on SH with shared libraries and the new toolchain. Cool, that's pretty impressive... I assume from your use of X you're working on a dreamcast or an SH handheld PC? I am working on a deeply embedded target where running X would be insane overkill, not to mention impossible =) > I am currently away from my computer that has all of the patches. If you > can wait until tonight (Melbourne time) I will post you the patches. I > fact I will try to get them onto the linuxsh patch manager. Alright, either (or both) would be great. Thanks again for your assistance... Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Greg B. <gb...@po...> - 2001-01-05 04:08:22
|
Bryan Rittmeyer wrote: > > Hello, > > After a couple of months of using the older toolchain (from around 8/00) > I have run into some problems that I suspect may have been addressed by > the efforts since then. But after falling partially out of the loop I've > lost track of toolchain/kernel development progress and have the > following questions: > > 1. Where can I get the latest versions of gcc, binutils, glibc, etc? Is > the LinuxSH CVS repository up to date, or are they only availible as tar > archives on an ftp/web server? The situation is a bit messy at the moment. The LinuxSH guys who handle the toolchain are in the process of merging back toolchain sources with the GNU team, which leaves us with something of a fluid situation. The LinuxSH CVS repository modules "gcc-core" and "binutils" are *not* the latest versions. They do, however, form a complete older version of the toolchain which you can use to compile the kernel with only a small kernel patch. I just uploaded to sourceforge Patch Manager this patch which lets you build the sourceforge CVS kernel with the sourceforge CVS toolchain. It worked for me when I merged in 2.4.0-test12 a few days ago. Good luck. http://sourceforge.net/patch/?func=detailpatch&patch_id=103106&group_id=2682 Right now getting the latest toolchain to work is not easy. My colleague Denis Dowling has just demonstrated this ;-) > 2. Does this toolchain properly build the latest CVS kernel? Are the CVS > kernel sources still the latest? Sourceforge CVS kernel sources are always the latest. Sourceforge CVS toolchain is old and will wither and die, to be replaced with the standard GNU toolchain distro, "soon". Exactly when is not clear to me, but don't hold your breath. > 2. Are there build directions for these newer versions, similar to what > exists for the old toolchain on the LinuxSH website? If not, is anyone > able to supply working build instructions? Right now, no single concise and clear set of such instructions exist. In the last few days Denis has gathered (the hard way) enough information to write such a set of instructions, so perhaps it might soon exist. However, for the next couple of weeks we have some urgent priorities, so don't get your hopes up. > 3. What is the status of the SH merge into the main, upstream > gcc/glibc/binutils/kernel sources? Niibe-san is actively pursuing these, perhaps I should let him answer this...however I do know from Linus' change logs that kernel 2.4.0-test13-pre5 (IIRC) contained a large SuperH update. > 4. Does native GDB work correctly now? If not, what problems remain, > and, if anyone is working on them, how can I assist? Not sure. Haven't tested it recently. > I would greatly appreciate it if someone could bring me up to date, so > that I can track current development (as it happens) and offer my humble > assistance/patches.... I look forward to working with all of you once > again. No problem. I really should update the FAQ, it's very seriously outdated :-( Greg. -- These are my opinions not PPIs. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X