linuxsh-dev

[linuxsh-dev] Anybody used ext2 on SH?

[Alex B. <ker...@be...>]

Hi,

We've been testing our IDE interace on our SH based board and everything
was works fine except we occasionaly get crashes with code running off
the hard disk. We originally though it may be a problem with our IDE
code but it seems the fault is ext2 related as we can get the same
failure mode over ext2 on a loopback over nfs.

Have many people been using ext2 on SH platforms? 

-- 
Alex, homepage: http://www.bennee.com/~alex/

It was Penguin lust... at its ugliest.

Re: [linuxsh-dev] scripts/treelink.sh

[SUGIOKA T. <su...@it...>]

At 21:52 03/05/08 -0500, Paul Mundt <le...@li...> wrote:
>On Fri, May 09, 2003 at 10:23:06AM +0900, SUGIOKA Toshinobu wrote:
>> Well, I know what drop-in tree is. And I think it's something inconvenient
>> on some situation.
>> (1) There seems no simple way to see which files should be removed from 
>the stock kernel,
>>     so it's a bit hard to create complete patch against stock kernel from 
>drop-in tree.
>
>I don't see how this is hard, I usually extract mainline source into
>linux-2.5.xx.orig and then have a seperate directory where i treelink
>the drop-in tree over. If I want patches between the drop-in and
>mainline, I just diff against the .orig and the treelinked tree and add
>-x CVS to diff, this works fine for me.

I mean that unnecessary files are not removed by the patch which is created
by this procedure.

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] scripts/treelink.sh

[Paul M. <le...@li...>]

On Fri, May 09, 2003 at 10:23:06AM +0900, SUGIOKA Toshinobu wrote:
> Well, I know what drop-in tree is. And I think it's something inconvenient
> on some situation.
> (1) There seems no simple way to see which files should be removed from the stock kernel,
>     so it's a bit hard to create complete patch against stock kernel from drop-in tree.

I don't see how this is hard, I usually extract mainline source into
linux-2.5.xx.orig and then have a seperate directory where i treelink
the drop-in tree over. If I want patches between the drop-in and
mainline, I just diff against the .orig and the treelinked tree and add
-x CVS to diff, this works fine for me.

> (2) We can not automatically detect if these incorrect files are included in some source file by mistake,
>     because compiler may not complain.
> (3) Some one who want to analyze the kernel source of sh-port might be confused by these useless files.
> (4) Once kernel maintainer synchronized stock kernel to our CVS tree, should we remove almost all files
>     from CVS tree ?, and soon in the next kernel version, should some files be restored and modified ?
>     Do you really want to do this ?
> 
That was my original intent. But I have scripts that deal with most of
this for me, so for instance if I go to apply a patch over the drop-in
tree, stock files are copied out from mainline tree before patch is run.

Either way, most of the "useless" files in mainline should be gone
shortly, since I just synced with mainline a little while ago.

> I don't want to accept these inconveniences. We could maintain whole arch/sh and include/asm-sh
> with a few transfer size penalty. It should be much better IMHO.
> 
I suppose its not a big deal either way, the size is pretty
minimalistic. If entire arch/sh and include/asm-sh is more convenient,
then we can certainly leave it that way as well. (At present there
shouldn't be too many files missing).

Re: [linuxsh-dev] scripts/treelink.sh

[SUGIOKA T. <su...@it...>]

At 10:34 03/05/08 -0500, Paul Mundt <le...@li...> wrote:
>On Thu, May 08, 2003 at 06:39:57PM +0900, SUGIOKA Toshinobu wrote:
>> Currently, after scripts/treelink.sh has done, we see many unnecessary 
>files in
>> arch/sh/kernel and include/asm-sh.
>> 
>The only reason some of these files are not needed are because they're
>left over garbage in mainline, once this stuff is synced back up,
>we can remove a lot of files from the drop-in tree.
>
>The purpose of the drop-in tree in the first place was to only include
>relevant files that needed local modification in order to be of use. If
>most of this stuff _already_ sits in mainline, then there's no need to
>track those files in the drop-in tree anymore. If someone needs to patch
>something on the other hand, then those files can be moved backed in,
>patched, and so forth.
>
>Especially since the drop-in tree already requires that it is applied
>against a stock kernel version, we don't lose out on anything here.
>
>> This is because treelink.sh can not remove any files in stock kernel.
>> 
>Again, most of these useless files will be removed from mainline, so
>there's nothing to worry about here.

Well, I know what drop-in tree is. And I think it's something inconvenient
on some situation.
(1) There seems no simple way to see which files should be removed from the stock kernel,
    so it's a bit hard to create complete patch against stock kernel from drop-in tree.
(2) We can not automatically detect if these incorrect files are included in some source file by mistake,
    because compiler may not complain.
(3) Some one who want to analyze the kernel source of sh-port might be confused by these useless files.
(4) Once kernel maintainer synchronized stock kernel to our CVS tree, should we remove almost all files
    from CVS tree ?, and soon in the next kernel version, should some files be restored and modified ?
    Do you really want to do this ?

I don't want to accept these inconveniences. We could maintain whole arch/sh and include/asm-sh
with a few transfer size penalty. It should be much better IMHO.

----
SUGIOKA Toshinobu

[linuxsh-dev] Re: a 2.5.69 local patch

[SUGIOKA T. <su...@it...>]

At 18:18 03/05/07 +0900, SUGIOKA Toshinobu <su...@it...> wrote:
>At 17:56 03/05/06 +0900, kaz Kojima <kk...@rr...> wrote:
>>I've just put the latter:
>><URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-2.5.69-local.diff.bz2>
>
>Thanks a lot. I tried this patch on my SH-7750R (which has 2-way cache) board.
>With a few changes, it worked very well.
>X window system with vnc-server runs on this kernel.

There was a missing file in the patch.

--- /dev/null   Thu Apr 11 23:25:15 2002
+++ linux-sh-2.5.69-kkojima-mod/arch/sh/boot/compressed/vmlinux.scr     Mon Apr 14 11:33:33 2003
@@ -0,0 +1,9 @@
+SECTIONS
+{
+  .data : {
+       input_len = .;
+       LONG(input_data_end - input_data) input_data = .;
+       *(.data)
+       input_data_end = .;
+       }
+}


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] scripts/treelink.sh

[Paul M. <le...@li...>]

On Thu, May 08, 2003 at 06:39:57PM +0900, SUGIOKA Toshinobu wrote:
> Currently, after scripts/treelink.sh has done, we see many unnecessary files in
> arch/sh/kernel and include/asm-sh.
> 
The only reason some of these files are not needed are because they're
left over garbage in mainline, once this stuff is synced back up,
we can remove a lot of files from the drop-in tree.

The purpose of the drop-in tree in the first place was to only include
relevant files that needed local modification in order to be of use. If
most of this stuff _already_ sits in mainline, then there's no need to
track those files in the drop-in tree anymore. If someone needs to patch
something on the other hand, then those files can be moved backed in,
patched, and so forth.

Especially since the drop-in tree already requires that it is applied
against a stock kernel version, we don't lose out on anything here.

> This is because treelink.sh can not remove any files in stock kernel.
> 
Again, most of these useless files will be removed from mainline, so
there's nothing to worry about here.

[linuxsh-dev] scripts/treelink.sh

[SUGIOKA T. <su...@it...>]

Hi, All.

Currently, after scripts/treelink.sh has done, we see many unnecessary files in
arch/sh/kernel and include/asm-sh.

This is because treelink.sh can not remove any files in stock kernel.

If we would always create symbolic link to arch/sh and include/asm-sh,
and there ware all necessary files for these two directories in drop-in-tree,
we wouldn't see garbages in these directories.

For this purpose, scripts/treelink.sh should be slightly modified.

Comments ?

Index: scripts/treelink.sh
===================================================================
RCS file: /cvsroot/linuxsh/linux/scripts/treelink.sh,v
retrieving revision 1.2
diff -u -r1.2 treelink.sh
--- scripts/treelink.sh 16 Oct 2001 21:33:00 -0000      1.2
+++ scripts/treelink.sh 8 May 2003 09:13:36 -0000
@@ -18,7 +18,11 @@
 cd $1 || exit 1
 LDIR=${PWD}
 echo -n "Building file list ... "
-LIST=`find * \( -type d -name CVS -prune \) -o -type f -print`
+LIST="arch/sh include/asm-sh \
+     `find * \( -type d -name CVS -prune \) \
+          -o \( -type d -name sh -prune \) \
+          -o \( -type d -name asm-sh -prune \) \
+          -o -type f -print`"
 echo -e "done."
 cd ${ODIR}

@@ -31,7 +35,11 @@
                DIR=`dirname $file`
                ofile=`basename $file`
                [ ! -d ${DIR}/.orig ] && mkdir -p ${DIR}/.orig
-               cp $file ${DIR}/.orig/$ofile
+               if [ ! -d $file ]; then
+                       cp $file ${DIR}/.orig/$ofile
+               else
+                       mv $file ${DIR}/.orig/$ofile
+               fi
        fi
 done
 echo -e "done."

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] Re: a 2.5.69 local patch

[Paul M. <le...@li...>]

On Thu, May 08, 2003 at 12:53:16PM +0900, SUGIOKA Toshinobu wrote:
> flush_icache_range(unsigned long start, unsigned long end) in HEAD doesn't work anyway.
> This function is used in fs/binfmt_elf.c and requires flush range from
> start to end, but in HEAD version, it flushes only 1 line (32byte).
> I think it's better to flush whole i-cache because the range may be very large.

Okay, agreed. In the future, I think we may want to do slightly more
intelligent bounds checking to verify whether flushing the entire icache
is faster or not, but that'll require a bit of careful profiling. (Such
as only flushing parts when the range is small and flushing the whole
thing when its over a predetermined threshold).

> Well, I know that fixups. but...
> (1) On older SH-4 CPUs, current 2.4 branch works well. These functions are oprimized for
>     these CPUs, but they assumes direct mapped cache so we can't use on 2-way cache.
>     That fixups simply extends address range for pre-loading to flush d-cache.
>     I think this is a bit dangerous because LRU bit may not work always for this purpose.
>     And anyway, there is more efficient method to flush 2-way cache.
> 
> (2) On new type CPUs that have 2-way cache system, we have no restriction to access
>     operand cache address array, so we can flush d-cache by clearing this array without
>     performance penalty.
> 
Okay, performance is what I was primarily concerned with, the old method
for flushing out the direct-mapped will certainly suffer with 2-way, and
even moreso with 4-way. With no access restriction on the OC addr array,
that definitely seems like the optimal way to go.

Time to re-examine the SH-2 caches..

> (3) I don't like the code like this, because it is hard to maintain.
> +	mov.l	@(56,r6),r1        ! cpu_data->dcache.ways
> 
Agreed. However, this is hardly isolated, entry.S does quite a bit of
this as well.

> (4) We don't need to consider multi-way in functions that use flush_cache_4096(),
>     ASSOC bit works for that.
>     flush_dcache_page() and __flush_cache_page() in 2.4 branch seems work without any change.
> 
Okay, I hadn't looked into that, but that's certainly good. It'll help
with performance.

Feel free to check this stuff in then, things appear to still work on
the stock 7750 with these changes.. and this should finally put an end
to the 7750R/7751R nonsense.

[linuxsh-dev] Re: a 2.5.69 local patch

[SUGIOKA T. <su...@it...>]

At 16:45 03/05/07 -0500, Paul Mundt <le...@li...> wrote:
>On Wed, May 07, 2003 at 06:18:11PM +0900, SUGIOKA Toshinobu wrote:
>> Thanks a lot. I tried this patch on my SH-7750R (which has 2-way cache) board.
>> With a few changes, it worked very well.
>> X window system with vnc-server runs on this kernel.
>> 
>Okay, overall this looks good, though I have a few suggestions. For one,
>I just fixed up flush_icache_range() in HEAD to clear out the valid bit
>per-way, which it wasn't doing before. Please try this first and see if
>it works for you. If it turns out that flush_cache_all() is faster, then
>obviously we can use that, but I'd like to avoid excessive flushing.
>

flush_icache_range(unsigned long start, unsigned long end) in HEAD doesn't work anyway.
This function is used in fs/binfmt_elf.c and requires flush range from
start to end, but in HEAD version, it flushes only 1 line (32byte).
I think it's better to flush whole i-cache because the range may be very large.
It seems that this function is same as previous version of flush_cache_sigtramp().
flush_cache_sigtramp() is the optimized version for signal trampoline which needs
only 1 line being flushed.

  # 2-cache-lines are write-backed on my patch, but 1-line should be sufficient for now.

>Secondly, there were a few fixups posted earlier for
>__flush_dcache_all() and flush_cache_4096_all() to deal with the new
>cache layout (including multiple ways), which also has been reported as
>working for 7750R and 7751R. In this case, I'd prefer to merge these
>cleanups first and then take a look at the rest of your fixes to see
>what is still relevant.

Well, I know that fixups. but...
(1) On older SH-4 CPUs, current 2.4 branch works well. These functions are oprimized for
    these CPUs, but they assumes direct mapped cache so we can't use on 2-way cache.
    That fixups simply extends address range for pre-loading to flush d-cache.
    I think this is a bit dangerous because LRU bit may not work always for this purpose.
    And anyway, there is more efficient method to flush 2-way cache.

(2) On new type CPUs that have 2-way cache system, we have no restriction to access
    operand cache address array, so we can flush d-cache by clearing this array without
    performance penalty.

(3) I don't like the code like this, because it is hard to maintain.
+	mov.l	@(56,r6),r1        ! cpu_data->dcache.ways

(4) We don't need to consider multi-way in functions that use flush_cache_4096(),
    ASSOC bit works for that.
    flush_dcache_page() and __flush_cache_page() in 2.4 branch seems work without any change.

For performance reason, I consider that it's better to use different cache flushing method
for 2-way cache from that for direct-mapped cache.

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] A New Source Distribution with SH3/SH4 support

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> On Thu, May 08, 2003 at 10:32:01AM +1000, David McCullough wrote:
> > On the SH front it supports the Hitachi Tahoe (SH4-7751) and
> > KeyWest (SH3-7729 DSP) evaluation boards out of the box as well as
> > targets for the SH based SnapGear Routers.
> > 
> > The 2.4 kernel has a working V320 PCI driver and kernel support for the
> > SH3 DSP and an X/Y memory driver,  allowing apps to take advantage of
> > the DSP.
>
> For those of us that are bandwidth impaired (not to mention, I've not
> been able to connect to the ftp), are there available patches somewhere
> of just the kernel modifications?

Not currently though I could generate some against 2.4.20 if you like.
Might take me a little while to put together.  Are you interested in all
changes or just arch/sh and include/asm-sh for now ?

Most,  if not all of the code is,  believe it or not,  available on the
cvs.uclinux.org.  You can browse the files at:

	http://cvs.uclinux.org/cgi-bin/cvsweb/uClinux-2.4.x

and

	http://cvs.uclinux.org/cgi-bin/cvsweb/uClinux-dist

You can also download the uClinux version of the dist (same source with
a different name) at:

	http://www.uclinux.org/pub/uClinux/dist/

The reason for the name change was for all the people who think
uClinux != linux and assume it will not work on MMU enabled systems ;-)

Unfortunately the snapgear ftp site has been choked up since the announcement,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linuxsh-dev] A New Source Distribution with SH3/SH4 support

[Paul M. <le...@li...>]

On Thu, May 08, 2003 at 10:32:01AM +1000, David McCullough wrote:
> On the SH front it supports the Hitachi Tahoe (SH4-7751) and
> KeyWest (SH3-7729 DSP) evaluation boards out of the box as well as
> targets for the SH based SnapGear Routers.
> 
> The 2.4 kernel has a working V320 PCI driver and kernel support for the
> SH3 DSP and an X/Y memory driver,  allowing apps to take advantage of
> the DSP.
> 
For those of us that are bandwidth impaired (not to mention, I've not
been able to connect to the ftp), are there available patches somewhere
of just the kernel modifications?

[linuxsh-dev] A New Source Distribution with SH3/SH4 support

[David M. <da...@sn...>]

Hi all,

In case you haven't seen the announcement floating around.  SnapGear has
released a new full source distribution for embedded linux devices.

You can read the Marketing hype here:

	http://www.ucdot.org/article.pl?sid=03/04/29/0130237

You can download the distribution for free or order it on CD for $25USD
at:

	http://www.snapgear.org/

The distribution includes a 2.4.20 kernel,  uClibc-0.9.19, glibc-2.2.5
and a large number of point and click selectable apps using the kernel
config system for libs and apps as well.  Some of the notable apps
included are busybox, pcmcia-cs, freeswan, zebra, boa, snort, wireless tools,
dhcp, ppp and lots more.  All up there is over 150 user apps included
as full source.

On the SH front it supports the Hitachi Tahoe (SH4-7751) and
KeyWest (SH3-7729 DSP) evaluation boards out of the box as well as
targets for the SH based SnapGear Routers.

The 2.4 kernel has a working V320 PCI driver and kernel support for the
SH3 DSP and an X/Y memory driver,  allowing apps to take advantage of
the DSP.

Anyways,  I thought it might be of interest to the linuxsh-dev crowd,

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linux-sh:02725] Re: [linuxsh-dev] a 2.5.69 local patch

[Paul M. <le...@li...>]

On Wed, May 07, 2003 at 06:18:11PM +0900, SUGIOKA Toshinobu wrote:
> Thanks a lot. I tried this patch on my SH-7750R (which has 2-way cache) board.
> With a few changes, it worked very well.
> X window system with vnc-server runs on this kernel.
> 
Okay, overall this looks good, though I have a few suggestions. For one,
I just fixed up flush_icache_range() in HEAD to clear out the valid bit
per-way, which it wasn't doing before. Please try this first and see if
it works for you. If it turns out that flush_cache_all() is faster, then
obviously we can use that, but I'd like to avoid excessive flushing.

Secondly, there were a few fixups posted earlier for
__flush_dcache_all() and flush_cache_4096_all() to deal with the new
cache layout (including multiple ways), which also has been reported as
working for 7750R and 7751R. In this case, I'd prefer to merge these
cleanups first and then take a look at the rest of your fixes to see
what is still relevant.

[linuxsh-dev] Re: a 2.5.69 local patch

[kaz K. <kk...@rr...>]

SUGIOKA Toshinobu <su...@it...> wrote:
> At 17:56 03/05/06 +0900, kaz Kojima <kk...@rr...> wrote:
>>I've just put the latter:
>><URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-2.5.69-local.diff.bz2>
> 
> Thanks a lot. I tried this patch on my SH-7750R (which has 2-way cache) board.
> With a few changes, it worked very well.
> X window system with vnc-server runs on this kernel.

Great!

I renamed patch-2.5.69-local.diff.bz2 to patch-2.5.69-local-20030506.diff.bz2
and updated the above patch-2.5.69-local.diff.bz2 with your patch and a tiny
workaround for __udivdi3 problem.

Regards,
	kaz

Re: [linux-sh:02716] Re: [linuxsh-dev] a 2.5.69 local patch

[SUGIOKA T. <su...@it...>]

At 17:56 03/05/06 +0900, kaz Kojima <kk...@rr...> wrote:
>I've just put the latter:
><URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-2.5.69-local.diff.bz2>

Thanks a lot. I tried this patch on my SH-7750R (which has 2-way cache) board.
With a few changes, it worked very well.
X window system with vnc-server runs on this kernel.

Regards,
    SUGIOKA Toshinobu

[linuxsh-dev] 2.5.69 linux/time.h

[kaz K. <kk...@rr...>]

Hi,

Sugioka-san pointed me that the most recent change of linux/time.h
in 2.5.69 produces 64-bit/64-bit unsigned integer divisions and calls
__udivdi3 in libgcc.a. It causes a bug with using FPU badly in SH-4
kernel. So I've checked an attached patch in on HEAD as a temporary
workaround for it.
These divisions come from the computation with TICK_NSEC(TICK_USEC)
which is non-constant for SH only and it looks to me that only
64-bit/32-bit divisions are required.
We have to write true 64-bit/64-bit one if it's not the case.

Regards,
	kaz
--
2003-05-07  Kaz Kojima  <kk...@rr...>

	* arch/sh/lib/udivdi3.c: New file.
	* arch/sh/lib/Makefile (obj-y): Add udivdi3.o.

diff -u3prN linux-2.5.69-orig/arch/sh/lib/Makefile LOCAL/linux-2.5.69-sf/arch/sh/lib/Makefile
--- linux-2.5.69-orig/arch/sh/lib/Makefile	Wed Mar  5 12:29:18 2003
+++ LOCAL/linux-2.5.69-sf/arch/sh/lib/Makefile	Tue May  6 20:15:31 2003
@@ -4,4 +4,4 @@
 
 L_TARGET = lib.a
 obj-y  = delay.o memcpy.o memset.o memmove.o memchr.o \
-	 checksum.o strcasecmp.o strlen.o div64.o
+	 checksum.o strcasecmp.o strlen.o div64.o udivdi3.o
diff -u3prN linux-2.5.69-orig/arch/sh/lib/udivdi3.c LOCAL/linux-2.5.69-sf/arch/sh/lib/udivdi3.c
--- linux-2.5.69-orig/arch/sh/lib/udivdi3.c	Thu Jan  1 09:00:00 1970
+++ LOCAL/linux-2.5.69-sf/arch/sh/lib/udivdi3.c	Tue May  6 20:14:57 2003
@@ -0,0 +1,16 @@
+/*
+ * Simple __udivdi3 function which doesn't use FPU.
+ */
+
+#include <linux/types.h>
+
+extern u64 __div64_32(u64 n, u32 d);
+extern void panic(const char * fmt, ...);
+
+u64 __udivdi3(u64 n, u64 d)
+{
+	if (d & ~0xffffffff)
+		panic("Need true 64-bit/64-bit division");
+	return __div64_32(n, (u32)d);
+}
+

[linuxsh-dev] Re: __fpscr_values

[kaz K. <kk...@rr...>]

Daniel Jacobowitz <dr...@fa...> wrote:
> I want to add that moving it to libc wouldn't hurt that case: they'd
> get a unique copy when loaded.

Agreed again. There is no runtime problem if it moved to libc.so
or anywhere "always exists". -z defs issue only.
 
>>> I'd have to think about it... I think it makes more sense in libc. 
>> 
>> I have no strong sense about where it is placed if it's unique.
>> Once Niibe-san proposed libfpscr.so-like which is an "always linked"
>> shared library as an another possibility.
> 
> Do you mind if I ask libc-alpha for opinions?  Roland, Jakub, et al.
> are a lot more on top of this than I am.  I can just force -z nodefs
> for now, but I'm not happy with that as a solution.

Of course, no problem.

Regards,
	kaz

[linuxsh-dev] Re: __fpscr_values

[Daniel J. <dr...@fa...>]

On Wed, May 07, 2003 at 11:18:00AM +0900, kaz Kojima wrote:
> Daniel Jacobowitz <dr...@fa...> wrote:
> >> But some shared libraries can be made without libc, can't be?
> >> -z defs issue remains for them.
> > 
> > They shouldn't be; it causes all sorts of problems with for instance
> > prelinking.
> 
> I agree with you, though my point is can/cannot.

I want to add that moving it to libc wouldn't hurt that case: they'd
get a unique copy when loaded.

> >> Of course, we can treat them as the exceptions, but it seems to me
> >> it's not essentially different with the current crt1.o implementation.
> > 
> > I'd have to think about it... I think it makes more sense in libc. 
> 
> I have no strong sense about where it is placed if it's unique.
> Once Niibe-san proposed libfpscr.so-like which is an "always linked"
> shared library as an another possibility.

Do you mind if I ask libc-alpha for opinions?  Roland, Jakub, et al.
are a lot more on top of this than I am.  I can just force -z nodefs
for now, but I'm not happy with that as a solution.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[linuxsh-dev] Re: __fpscr_values

[kaz K. <kk...@rr...>]

Daniel Jacobowitz <dr...@fa...> wrote:
>> But some shared libraries can be made without libc, can't be?
>> -z defs issue remains for them.
> 
> They shouldn't be; it causes all sorts of problems with for instance
> prelinking.

I agree with you, though my point is can/cannot.
 
>> Of course, we can treat them as the exceptions, but it seems to me
>> it's not essentially different with the current crt1.o implementation.
> 
> I'd have to think about it... I think it makes more sense in libc. 

I have no strong sense about where it is placed if it's unique.
Once Niibe-san proposed libfpscr.so-like which is an "always linked"
shared library as an another possibility.

Regards,
	kaz

[linuxsh-dev] Re: __fpscr_values

[Daniel J. <dr...@fa...>]

On Wed, May 07, 2003 at 10:21:02AM +0900, kaz Kojima wrote:
> Daniel Jacobowitz <dr...@fa...> wrote:
> > At the risk of missing something obvious... why not put it in libc.so
> > and libc.a (not libc_nonshared.a) directly if all you want is for it to
> > be unique in the executable?  There is always exactly one copy of libc
> > loaded, and everything should be dynamically linked to it except for
> > ld.so.
> 
> But some shared libraries can be made without libc, can't be?
> -z defs issue remains for them.

They shouldn't be; it causes all sorts of problems with for instance
prelinking.

> Of course, we can treat them as the exceptions, but it seems to me
> it's not essentially different with the current crt1.o implementation.

I'd have to think about it... I think it makes more sense in libc. 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[linuxsh-dev] Re: __fpscr_values

[kaz K. <kk...@rr...>]

Daniel Jacobowitz <dr...@fa...> wrote:
> At the risk of missing something obvious... why not put it in libc.so
> and libc.a (not libc_nonshared.a) directly if all you want is for it to
> be unique in the executable?  There is always exactly one copy of libc
> loaded, and everything should be dynamically linked to it except for
> ld.so.

But some shared libraries can be made without libc, can't be?
-z defs issue remains for them.
Of course, we can treat them as the exceptions, but it seems to me
it's not essentially different with the current crt1.o implementation.

Regards,
	kaz

[linuxsh-dev] Re: __fpscr_values

[Daniel J. <dr...@fa...>]

On Wed, May 07, 2003 at 09:13:42AM +0900, kaz Kojima wrote:
> Hi,
> 
> >I feel like every time I upgrade tools I spend a day chasing after
> >__fpscr_values...
> >
> >Kaz, it looks like the current state of the tools has it in (for
> >Linux) start.S in glibc, which puts it in crt1.o.  That means there's
> >no copy of it in libm; just references to it.  But libm is built with
> >-z defs, so the undefined reference is an error.
> >
> >Why did it move out of crti.o?
> 
> Because it should be an unique object in the execution. FPSCR
> has the bits to control the behavior for math exceptions and
> if there are multiple __fpscr_values objects, we can't control
> this behavior.
> 
> To avoid -z defs issue, you could use no-z-defs=yes in libc
> configparms. Yes, it removes all useful checks with -z defs,
> but...
> It might be better to add a new ld option to allow an exception
> for -z defs something like --allow-shlib-undefined-sym SYMBOL.
> 
> Anyway, sorry for forgetting to write this issue to these list.
> About __fpscr_values issue itself, Joern Rennecke and Alexandre
> Oliva said independently to me that one solution is to give a
> fixed address for __fpscr_values and support it by GCC.
> Perhaps stack top would be a candidate.

At the risk of missing something obvious... why not put it in libc.so
and libc.a (not libc_nonshared.a) directly if all you want is for it to
be unique in the executable?  There is always exactly one copy of libc
loaded, and everything should be dynamically linked to it except for
ld.so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[linuxsh-dev] Re: __fpscr_values

[kaz K. <kk...@rr...>]

Hi,

>I feel like every time I upgrade tools I spend a day chasing after
>__fpscr_values...
>
>Kaz, it looks like the current state of the tools has it in (for
>Linux) start.S in glibc, which puts it in crt1.o.  That means there's
>no copy of it in libm; just references to it.  But libm is built with
>-z defs, so the undefined reference is an error.
>
>Why did it move out of crti.o?

Because it should be an unique object in the execution. FPSCR
has the bits to control the behavior for math exceptions and
if there are multiple __fpscr_values objects, we can't control
this behavior.

To avoid -z defs issue, you could use no-z-defs=yes in libc
configparms. Yes, it removes all useful checks with -z defs,
but...
It might be better to add a new ld option to allow an exception
for -z defs something like --allow-shlib-undefined-sym SYMBOL.

Anyway, sorry for forgetting to write this issue to these list.
About __fpscr_values issue itself, Joern Rennecke and Alexandre
Oliva said independently to me that one solution is to give a
fixed address for __fpscr_values and support it by GCC.
Perhaps stack top would be a candidate.

Regards,
	kaz

Re: [linuxsh-dev] a 2.5.69 local patch

[kaz K. <kk...@rr...>]

SUGIOKA Toshinobu <su...@it...> wrote:
>>The attached list is the ChangeLog of this local patch. The patch itself
>>is slightly big to attach here as a plain text, so I put it at:
>><URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-sf-20030506.diff.bz2>.
> 
> umm.. it can not be applied to the current HEAD.
> Could you please upload whole drop-in-tree or diffs against vanilla kernel ?

I've just put the latter:
<URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-2.5.69-local.diff.bz2>
Sorry for inconvenience.

Regards,
	kaz

Re: [linuxsh-dev] a 2.5.69 local patch

[SUGIOKA T. <su...@it...>]

At 16:30 03/05/06 +0900, kaz Kojima <kk...@rr...> wrote:
>The attached list is the ChangeLog of this local patch. The patch itself
>is slightly big to attach here as a plain text, so I put it at:
><URL:http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-sf-20030506.diff.bz2>.

umm.. it can not be applied to the current HEAD.
Could you please upload whole drop-in-tree or diffs against vanilla kernel ?
Thanks.

----
SUGIOKA Toshinobu