Menu
▾
▴
linuxsh-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
| 2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
| 2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
| 2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
| 2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
| 2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
| 2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
| 2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
|
From: Bryan R. <br...@ix...> - 2001-01-13 20:15:36
|
Denis Dowling wrote: > I am trying to chace down a problem with popen() and pclose() using the > latest 2.4.0 kernel on the SuperH. I seems that waitpid is always > returning ECHILD even when the child process pid is correct and the > process has exited correctly. Is anyone else seeing this? Yep. Interestingly enough, it shows up with the latest CVS version of BusyBox, but not with the 0.48 BusyBox release (or maybe vice versa, I don't remember exactly). I started noticing it after moving from -test10 to 2.4.0, but I also changed binutils / gcc / glibc at the same time. Not precisely sure it's a kernel problem... Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Denis D. <ddo...@po...> - 2001-01-11 16:20:12
|
Hello All, I am trying to chace down a problem with popen() and pclose() using the latest 2.4.0 kernel on the SuperH. I seems that waitpid is always returning ECHILD even when the child process pid is correct and the process has exited correctly. Is anyone else seeing this? A simple test program that demonstrates this is attached. It should list the files in the current directory and then output "exited with status 0". On the SuperH I get a -1 returned from pclose(). Originally I thought this was a problem with glibc2.2 but have updated to the very latest 2.2.1pre2 libc and this problem still exists. I am now thinking that the waitpid system call is to blame. Is anyone else seeing this? Regards, Denis. |
|
From: Bryan R. <br...@ix...> - 2001-01-10 08:02:43
|
NIIBE Yutaka wrote: > I fogot about the symbol reference from sh_ksyms.c... > > We need following patch: ok, cool. heh... I was just starting to recompile gcc with "--target sh4-linux-gnu" in the hopes that would fix it. Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: NIIBE Y. <gn...@m1...> - 2001-01-10 07:55:36
|
Bryan Rittmeyer writes: > yeah, dumbwad.. it's the same problem! NIIBE-san, I think the prior > patch forgot to fix properly the SR register. Here's my additional patch > (I assume SOFF_R is a typo for OFF_SR): Thanks. > In any event, I have a more serious problem now with the linker: I fogot about the symbol reference from sh_ksyms.c... We need following patch: Index: arch/sh/kernel/sh_ksyms.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/sh_ksyms.c,v retrieving revision 1.9 diff -u -r1.9 sh_ksyms.c --- arch/sh/kernel/sh_ksyms.c 2001/01/02 16:54:19 1.9 +++ arch/sh/kernel/sh_ksyms.c 2001/01/10 07:53:05 @@ -66,8 +66,6 @@ /* These symbols are generated by the compiler itself */ #ifdef __SH4__ -DECLARE_EXPORT(__udivsi3_i4); -DECLARE_EXPORT(__sdivsi3_i4); DECLARE_EXPORT(__movstr_i4_even); DECLARE_EXPORT(__movstr_i4_odd); DECLARE_EXPORT(__ashrdi3); -- |
|
From: Bryan R. <br...@ix...> - 2001-01-10 07:47:11
|
Bryan Rittmeyer [AKA me] wrote:
> Anybody seen THIS one? Looks like its also binutils related...
yeah, dumbwad.. it's the same problem! NIIBE-san, I think the prior
patch forgot to fix properly the SR register. Here's my additional patch
(I assume SOFF_R is a typo for OFF_SR):
--- arch/sh/kernel/entry.S-2 Tue Jan 9 23:37:05 2001
+++ arch/sh/kernel/entry.S Tue Jan 9 23:38:04 2001
@@ -98,7 +98,7 @@
OFF_R6 = 24 /* New ABI: arg2 */
OFF_R7 = 28 /* New ABI: arg3 */
OFF_SP = (15*4)
-SOFF_R = (16*4+8)
+OFF_SR = (16*4+8)
SYSCALL_NR = (16*4+6*4)
@@ -265,7 +265,7 @@
.align 2
debug_trap:
#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) ||
defined(CONFIG_SH_STANDARD_BIOS)
- mov #SR, r0
+ mov #OFF_SR, r0
mov.l @(r0,r15), r0 ! get status register
shll r0
shll r0 ! kernel space?
@@ -504,7 +504,7 @@
1: .long SYMBOL_NAME(schedule)
ENTRY(ret_from_irq)
- mov #SR, r0
+ mov #OFF_SR, r0
mov.l @(r0,r15), r0 ! get status register
shll r0
shll r0 ! kernel space?
@@ -515,7 +515,7 @@
nop
ENTRY(ret_from_exception)
- mov #SR, r0
+ mov #OFF_SR, r0
mov.l @(r0,r15), r0 ! get status register
shll r0
shll r0 ! kernel space?
Not sure if this is actually correct, but at least it makes entry.S
assemble. :)
In any event, I have a more serious problem now with the linker:
sh-linux-gnu-ld -EL -T arch/sh/vmlinux.lds -e _stext
arch/sh/kernel/head.o arch/sh/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/sh/kernel/kernel.o arch/sh/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o \
net/network.o \
/home/bryan/tmp/kernel/arch/sh/lib/lib.a
/home/bryan/tmp/kernel/lib/lib.a
/home/bryan/tmp/kernel/arch/sh/lib/lib.a
/usr/local/sh/lib/gcc-lib/sh-linux-gnu/2.97/libgcc.a \
--end-group \
-o vmlinux
arch/sh/kernel/kernel.o(__ksymtab+0x1a8): undefined reference to
`__udivsi3_i4'
arch/sh/kernel/kernel.o(__ksymtab+0x1b0): undefined reference to
`__sdivsi3_i4'
make: *** [vmlinux] Error 1
I'm betting this is a libgcc.a problem?
Cheers,
Bryan
--
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
|
|
From: Bryan R. <br...@ix...> - 2001-01-10 07:34:49
|
NIIBE Yutaka wrote:
> I've just committed following change, I've got from Denis.
I believe the same thing needs to be done for SP?
--- arch/sh/kernel/entry.S-old Tue Jan 9 23:29:30 2001
+++ arch/sh/kernel/entry.S Tue Jan 9 23:30:19 2001
@@ -97,7 +97,7 @@
OFF_R5 = 20 /* New ABI: arg1 */
OFF_R6 = 24 /* New ABI: arg2 */
OFF_R7 = 28 /* New ABI: arg3 */
-SP = (15*4)
+OFF_SP = (15*4)
SOFF_R = (16*4+8)
SYSCALL_NR = (16*4+6*4)
@@ -431,7 +431,7 @@
mov r8, r10
cmp/pl r10
bf 0f
- mov.l @(SP,r15), r0 ! get original user stack
+ mov.l @(OFF_SP,r15), r0 ! get original user stack
7: add #-4, r10
4: mov.l @(r0,r10), r1 ! May cause address error exception..
mov.l r1, @-r15
With that patch applied, that specific entry.S error goes away. However,
I've got a new one now :(
sh-linux-gnu-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/home/bryan/tmp/kernel/include -ml -m4-nofpu -c -o entry.o entry.S
entry.S: Assembler messages:
entry.S:507: Error: Cannot represent relocation type BFD_RELOC_SH_IMM8
entry.S:518: Error: Cannot represent relocation type BFD_RELOC_SH_IMM8
make[1]: *** [entry.o] Error 1
Anybody seen THIS one? Looks like its also binutils related...
Regards,
Bryan
--
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
|
|
From: NIIBE Y. <gn...@m1...> - 2001-01-10 07:18:07
|
Bryan Rittmeyer wrote: > sh-linux-gnu-gcc -D__ASSEMBLY__ -D__KERNEL__ > -I/home/bryan/tmp/kernel/include -ml -m4-nofpu -c -o entry.o entry.S > entry.S: Assembler messages: > entry.S:376: Error: must be @(r0,...) > entry.S:377: Error: must be @(r0,...) > entry.S:378: Error: must be @(r0,...) > entry.S:379: Error: must be @(r0,...) > entry.S:380: Error: must be @(r0,...) > entry.S:434: Error: must be @(r0,...) > make[1]: *** [entry.o] Error 1 > make[1]: Leaving directory `/home/bryan/tmp/kernel/arch/sh/kernel' I've just committed following change, I've got from Denis. 2001-01-10 Denis Dowling <dp...@pr...> * arch/sh/kernel/entry.S: Change RX-->OFF_RX. Index: arch/sh/kernel/entry.S =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/entry.S,v retrieving revision 1.30 diff -u -r1.30 entry.S --- arch/sh/kernel/entry.S 2001/01/02 16:03:51 1.30 +++ arch/sh/kernel/entry.S 2001/01/10 07:12:27 @@ -89,16 +89,16 @@ #endif /* Offsets to the stack */ -R0 = 0 /* Return value. New ABI also arg4 */ -R1 = 4 /* New ABI: arg5 */ -R2 = 8 /* New ABI: arg6 */ -R3 = 12 /* New ABI: syscall_nr */ -R4 = 16 /* New ABI: arg0 */ -R5 = 20 /* New ABI: arg1 */ -R6 = 24 /* New ABI: arg2 */ -R7 = 28 /* New ABI: arg3 */ +OFF_R0 = 0 /* Return value. New ABI also arg4 */ +OFF_R1 = 4 /* New ABI: arg5 */ +OFF_R2 = 8 /* New ABI: arg6 */ +OFF_R3 = 12 /* New ABI: syscall_nr */ +OFF_R4 = 16 /* New ABI: arg0 */ +OFF_R5 = 20 /* New ABI: arg1 */ +OFF_R6 = 24 /* New ABI: arg2 */ +OFF_R7 = 28 /* New ABI: arg3 */ SP = (15*4) -SR = (16*4+8) +SOFF_R = (16*4+8) SYSCALL_NR = (16*4+6*4) @@ -373,11 +373,11 @@ ! from the kernel stack anyway, so don't need ! to be reloaded here.) This allows the parent ! to rewrite system calls and args on the fly. - mov.l @(R4,r15), r4 ! arg0 - mov.l @(R5,r15), r5 - mov.l @(R6,r15), r6 - mov.l @(R7,r15), r7 ! arg3 - mov.l @(R3,r15), r3 ! syscall_nr + mov.l @(OFF_R4,r15), r4 ! arg0 + mov.l @(OFF_R5,r15), r5 + mov.l @(OFF_R6,r15), r6 + mov.l @(OFF_R7,r15), r7 ! arg3 + mov.l @(OFF_R3,r15), r3 ! syscall_nr ! Arrange for syscall_trace() to be called ! again as the system call returns. mov.l __syscall_ret_trace, r10 @@ -407,7 +407,7 @@ ! In case of trace syscall_ret_trace: - mov.l r0, @(R0,r15) ! save the return value + mov.l r0, @(OFF_R0,r15) ! save the return value mov.l __syscall_trace, r1 mova SYMBOL_NAME(ret_from_syscall), r0 jmp @r1 ! Call syscall_trace() which notifies superior @@ -535,7 +535,7 @@ /* fall through */ #endif syscall_ret: - mov.l r0, @(R0,r15) ! save the return value + mov.l r0, @(OFF_R0,r15) ! save the return value /* fall through */ ENTRY(ret_from_syscall) |
|
From: Greg B. <gb...@po...> - 2001-01-10 07:13:47
|
Bryan Rittmeyer wrote: > > Hello linuxsh-dev, > > Since updating to GNU CVS binutils (with Denis's sh patches) and the > 11/2000 gcc 2.97 snapshot (using again Denis's patches), I get the > following 2.4.0 compile error: > > sh-linux-gnu-gcc -D__ASSEMBLY__ -D__KERNEL__ > -I/home/bryan/tmp/kernel/include -ml -m4-nofpu -c -o entry.o entry.S > entry.S: Assembler messages: > entry.S:376: Error: must be @(r0,...) > entry.S:377: Error: must be @(r0,...) > entry.S:378: Error: must be @(r0,...) > entry.S:379: Error: must be @(r0,...) > entry.S:380: Error: must be @(r0,...) > entry.S:434: Error: must be @(r0,...) > make[1]: *** [entry.o] Error 1 > make[1]: Leaving directory `/home/bryan/tmp/kernel/arch/sh/kernel' > > Anybody else seen this before or know how to fix it? Yes. Denis doesn't appear to be logged in at the moment, so I'll explain for him. The latest toolchain handles register names case-insensitively, so e.g. R0 is the same as r0. In the old toolchain R0 was not a register name but a symbol. The LinuxSH entry.S happens to use R0 etc as symbols (indicating the offsets into the stack register save area for specific saved registers). As a result the newest toolchain gets confused with entry.S. Denis has a patch for this which changes the Rx constants to OFF_Rx. > > Cheers, > > Bryan > > P.S. Thanks again to everyone for bringing me up to speed on the latest > development... Only by explaining to others do we reach full understanding ourselves. Greg. -- These are my opinions not PPIs. |
|
From: Bryan R. <br...@ix...> - 2001-01-10 06:41:28
|
Hello linuxsh-dev, Since updating to GNU CVS binutils (with Denis's sh patches) and the 11/2000 gcc 2.97 snapshot (using again Denis's patches), I get the following 2.4.0 compile error: sh-linux-gnu-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/bryan/tmp/kernel/include -ml -m4-nofpu -c -o entry.o entry.S entry.S: Assembler messages: entry.S:376: Error: must be @(r0,...) entry.S:377: Error: must be @(r0,...) entry.S:378: Error: must be @(r0,...) entry.S:379: Error: must be @(r0,...) entry.S:380: Error: must be @(r0,...) entry.S:434: Error: must be @(r0,...) make[1]: *** [entry.o] Error 1 make[1]: Leaving directory `/home/bryan/tmp/kernel/arch/sh/kernel' Anybody else seen this before or know how to fix it? Cheers, Bryan P.S. Thanks again to everyone for bringing me up to speed on the latest development... -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
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: 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 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 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-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: Greg B. <gb...@po...> - 2001-01-09 02:16:56
|
fi...@gm... wrote: > > Hi all! > > I keep getting a segmentation fault in sh-linux-gnu-ld when compiling the > kernel. Oh great, yet another one. This happens when you use the latest kernel with the sourceforge CVS binutils. > I'm using the latest version of binutils (got it from CVS today - > 2001-01-08). Compiling binutils worked fine... Yeah. See the traffic over the last few days about toolchain versions and the latest kernel. In summary, you can either get a newer toolchain or apply this patch to your kernel source. http://sourceforge.net/patch/download.php?id=103106 Greg. -- These are my opinions not PPIs. |
|
From: <fi...@gm...> - 2001-01-08 19:55:26
|
Hi all!
I keep getting a segmentation fault in sh-linux-gnu-ld when compiling the
kernel. I'm using the latest version of binutils (got it from CVS today -
2001-01-08). Compiling binutils worked fine...
The last few lines I get:
sh-linux-gnu-ld -EL -T arch/sh/vmlinux.lds -e _stext arch/sh/kernel/head.o
arch/sh/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/sh/kernel/kernel.o arch/sh/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o
ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o drivers/parport/parport.a \
net/network.o \
/usr/src/kernel-sh-linux/arch/sh/lib/lib.a
/usr/src/kernel-sh-linux/lib/lib.a /usr/src/kernel-sh-linux/arch/sh/lib/lib.a
/usr/local/sh/lib/gcc-lib/sh-linux-gnu/2.95.2/libgcc.a \
--end-group \
-o vmlinux
make: *** [vmlinux] Segmentation fault (core dumped)
When opening sh-linux-gnu-ld with the core dump, it there's an error at
ldlang.c:1732...
Just a few lines out of the source code:
[...]
target = bfd_search_for_target (get_target, (void *) output_target);
if (command_line.endian == ENDIAN_BIG)
desired_endian = BFD_ENDIAN_BIG;
else
desired_endian = BFD_ENDIAN_LITTLE;
/* See if the target has the wrong endianness. This should not
happen
if the linker script has provided big and little endian alternatives,
but some scrips don't do this. */
if (target->byteorder != desired_endian)
{
[...]
target is a NULL-pointer, and when dereferencing it, ld of course
crashes... Seems the function bfd_search_for_target doesn't work correctly, but I
couldn't figure out what it was...
I guess you guys have some experience with this, so maybe someone can
helpme please??
If you need any other information, of course feel free to ask me for it
:)...
Thanx a lot!!
finr
PS: Sorry if this is a multiple post, I got an error message from GMX...
--
Sent through GMX FreeMail - http://www.gmx.net
|
|
From: Denis D. <dp...@pr...> - 2001-01-07 23:47:02
|
This time I will remember to attach the patch file. |
|
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: 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-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: Greg B. <gb...@po...> - 2001-01-05 07:03:34
|
Greg Banks wrote: > > Bryan Rittmeyer wrote: > > > > [...] "unterminated character constant" errors. [...] > > No, this is actually a Makefile problem. You need to have > the -traditional flag to the assembler runs, then the warnings about > unterminated char constants go away. Only a few days ago I checked > in some LinuxSH Makefile tweaks to make that happen properly. I'll > go see if they're still there. Ooops, my changes disappeared in the 2.4.0-test13-pre4 merge. I'll work on fixing the repository, but what you need to do is add the following line to the Makefile in the directories where you had this problem. EXTRA_AFLAGS := -traditional Greg. -- These are my opinions not PPIs. |
|
From: Greg B. <gb...@po...> - 2001-01-05 06:57:48
|
Bryan Rittmeyer wrote: > > Greg Banks wrote: > > > That's right. I said it compiles, I didn't say it compiles cleanly ;-) > > The situation with the new toolchain is currently even worse, due to the > > whole $ in register names business. > > Ugh. I just dealt with some pretty nasty stuff, even with the old > toolchain. Namely, the use of "'" in !'d assembly comments. Apparently, > they now cause "unterminated character constant" errors. I just went > through by hand and removed them from entry.S, memmove.S, etc... I never > saw this before with the old kernel code, and I have a hard time > believing it doesn't have any "'"s in ! comments, but oh well. > 2.4.0-prerelease is building now, with the old toolchain. No, this is actually a Makefile problem. You need to have the -traditional flag to the assembler runs, then the warnings about unterminated char constants go away. Only a few days ago I checked in some LinuxSH Makefile tweaks to make that happen properly. I'll go see if they're still there. Greg. -- These are my opinions not PPIs. |
|
From: Bryan R. <br...@ix...> - 2001-01-05 06:33:00
|
Greg Banks wrote: > That's right. I said it compiles, I didn't say it compiles cleanly ;-) > The situation with the new toolchain is currently even worse, due to the > whole $ in register names business. Ugh. I just dealt with some pretty nasty stuff, even with the old toolchain. Namely, the use of "'" in !'d assembly comments. Apparently, they now cause "unterminated character constant" errors. I just went through by hand and removed them from entry.S, memmove.S, etc... I never saw this before with the old kernel code, and I have a hard time believing it doesn't have any "'"s in ! comments, but oh well. 2.4.0-prerelease is building now, with the old toolchain. Shrug. New kernel and old tools still tops an old kernel with old tools... > Sure its a hack. But are you going to be mounting DVDs? Exactly my reasoning. :) Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
|
From: Greg B. <gb...@po...> - 2001-01-05 06:12:28
|
Bryan Rittmeyer wrote: > > Hi, > > I've been working on building the latest CVS kernel using the older > toolchain and gnb's patch: > http://sourceforge.net/patch/download.php?id=103106 > > and I keep getting lots of these: > > --- > sh-linux-gnu-gcc -D__KERNEL__ -I/home/bryan/src/sh/kernel/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -ml > -m4 -pipe -c -o init/main.o init/main.c > In file included from /home/bryan/src/sh/kernel/include/linux/fs.h:658, > from > /home/bryan/src/sh/kernel/include/linux/capability.h:17, > from > /home/bryan/src/sh/kernel/include/linux/binfmts.h:5, > from /home/bryan/src/sh/kernel/include/linux/sched.h:9, > from /home/bryan/src/sh/kernel/include/linux/mm.h:4, > from /home/bryan/src/sh/kernel/include/linux/slab.h:14, > from > /home/bryan/src/sh/kernel/include/linux/malloc.h:4, > from > /home/bryan/src/sh/kernel/include/linux/proc_fs.h:5, > from init/main.c:15: > /home/bryan/src/sh/kernel/include/linux/udf_fs_sb.h:21: warning: > ignoring pragma: pack > /home/bryan/src/sh/kernel/include/linux/udf_fs_sb.h:76: warning: > ignoring pragma: pack That's right. I said it compiles, I didn't say it compiles cleanly ;-) The situation with the new toolchain is currently even worse, due to the whole $ in register names business. > --- > > I've run into the same warning when porting some of our in-house code... > does the old toolchain not implement #pragma pack? If not, why not, and > will the new one? > > In the meantime, I've applied my following patch (hack?): > > --- udf_fs_sb-old.h Thu Jan 4 21:57:34 2001 > +++ udf_fs_sb.h Thu Jan 4 21:58:04 2001 > @@ -18,7 +18,9 @@ > #if !defined(_LINUX_UDF_FS_SB_H) > #define _LINUX_UDF_FS_SB_H > > +#if !defined(__sh__) > #pragma pack(1) > +#endif > > #define UDF_MAX_BLOCK_LOADED 8 > > @@ -73,7 +75,9 @@ > __u16 s_partition_flags; > }; > > +#if !defined(__sh__) > #pragma pack() > +#endif > > struct udf_sb_info > { > Sure its a hack. But are you going to be mounting DVDs? Greg. -- These are my opinions not PPIs. |
|
From: Bryan R. <br...@ix...> - 2001-01-05 06:00:05
|
Hi, I've been working on building the latest CVS kernel using the older toolchain and gnb's patch: http://sourceforge.net/patch/download.php?id=103106 and I keep getting lots of these: --- sh-linux-gnu-gcc -D__KERNEL__ -I/home/bryan/src/sh/kernel/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -ml -m4 -pipe -c -o init/main.o init/main.c In file included from /home/bryan/src/sh/kernel/include/linux/fs.h:658, from /home/bryan/src/sh/kernel/include/linux/capability.h:17, from /home/bryan/src/sh/kernel/include/linux/binfmts.h:5, from /home/bryan/src/sh/kernel/include/linux/sched.h:9, from /home/bryan/src/sh/kernel/include/linux/mm.h:4, from /home/bryan/src/sh/kernel/include/linux/slab.h:14, from /home/bryan/src/sh/kernel/include/linux/malloc.h:4, from /home/bryan/src/sh/kernel/include/linux/proc_fs.h:5, from init/main.c:15: /home/bryan/src/sh/kernel/include/linux/udf_fs_sb.h:21: warning: ignoring pragma: pack /home/bryan/src/sh/kernel/include/linux/udf_fs_sb.h:76: warning: ignoring pragma: pack --- I've run into the same warning when porting some of our in-house code... does the old toolchain not implement #pragma pack? If not, why not, and will the new one? In the meantime, I've applied my following patch (hack?): --- udf_fs_sb-old.h Thu Jan 4 21:57:34 2001 +++ udf_fs_sb.h Thu Jan 4 21:58:04 2001 @@ -18,7 +18,9 @@ #if !defined(_LINUX_UDF_FS_SB_H) #define _LINUX_UDF_FS_SB_H +#if !defined(__sh__) #pragma pack(1) +#endif #define UDF_MAX_BLOCK_LOADED 8 @@ -73,7 +75,9 @@ __u16 s_partition_flags; }; +#if !defined(__sh__) #pragma pack() +#endif struct udf_sb_info { --- Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 |
25 messages has been excluded from this view by a project administrator.
