linuxsh-dev

Re: [linuxsh-dev] Preparing for 2.5

[Stuart M. <Stu...@st...>]

On Oct 12,  9:13am, gn...@m1... wrote:
> Subject: [linuxsh-dev] Preparing for 2.5

I'll try and answer some of these, but as a lot of SH-5 progress is still
not public, I'll have to pass on some points.

>  > - What's up for 2.5?  When I met with NIIBE-san at LWE, he mentioned that
>  >   one of the main things he saw for 2.5 was the beginnings of SH5 support.
>  >   The SH5 has a dual-addressing mode, so we'll have to start working on
>  >   64-bit support for the backend, among other things.  Did anyone else have
>  >   agendas for 2.5?  With the new layout/restructuring, hopefully it'll be
>  >   a lot easier to add support for new boards and processors.
> 
> I was a bit optimistic.  At that time, I expected the development
> environment would be available soon to the public.  The real world is
> not like I expected.
> 
> Situation is different.  As of SH-3/SH-4, it's under control of Hitachi.
> For SH-5, it's SuperH, Inc., who is in charge of. 

SH-5 was jointly developed by Hitachi and ST Microelectronics (my
employer). Some time after development started the two companies
decided to form a separate company to licence the SH-5 core, in the
same way ARM and MIPS do. So they formed SuperH Inc as a new company,
with both Hitach and ST as shareholders.

Unfortunatly the formation of the new company has taken longer than
expected, and as effectivly SH-5 is a SuperH product, this has delayed
everything.

Personally, I wish both companies would have allowed open source
developers access before public release. A good model would have been the
way Intel handled the IA-64 and the Trillian Project. This allowed
developers access (admitidy with an NDA) to documentation, simulators etc.,
before public release, and more importantly allowed them to colaborate on
development, safe in the knowledge that when the chip was released, their
code could also be released publically.

However it would have been a big step for two companies who I suspect are
not very aware of the benefits of open source. We're trying, but it is
taking a while!

> For SH-5, it seems for me that it's quite difficult to begin the
> development.  I think that I can't do at my position.  For now,
> there's no publically available development environment, I mean, GCC
> and such.  Even the technical manual of SH-5 CPU is not available for
> public.
> 
> Perhaps, it could be available under NDA with SuperH, Inc.  However,
> it is very very very much difficult at my position (public servant) to
> sign NDA to specific company.
> 
> I won't go the direction to support SH-5, in near future, perhaps never.
> 
> I wish someone with experience could join the SH-5 kernel development.

It looks like a really nice CPU, and should be able to run Linux well.

>From a technical point of view, SH-5 should probably be regarded in the
same way as mips64 and sparc64. It is able to run SH-4 code, but from
a kernel perspective is probably best regarded as a separate CPU, if
you want to get the best out of it.

I wish I could say more, because there has been progress behind the scenes,
but until SuperH Inc. make the architecture public, a lot of other things
can't be made public either.

Stuart

Re: [linuxsh-dev] Preparing for 2.5

[Stuart M. <Stu...@st...>]

On Oct 12, 10:50am, mr...@0x... wrote:
> Subject: Re: [linuxsh-dev] Preparing for 2.5
> * Greg Banks <gn...@al...> on Fri, Oct 12, 2001:
> 
> > 
> >   Personally I think the runtime part of the machvec is fairly pointless;
> > it could all be compiletime instead.
> > 
> 
> Good idea.

Yes and no :-)

There were two main objectives I had when writing the mach_vec stuff:

 - to better separate the board, chip and CPU specific details

   The source code was and is growing a large number of board, chip and
   CPU specific ifdefs, and given that there are few standards SH based
   systems need to follow, this is probably going to get worse.

   The mach_vec is a useful way of enforcing this separation, and should
   make it easier for someone who is not an experienced kernel hacker to
   get the kernel up and running on some new hardware.

   Hopefully most people would agree this is a 'good thing'.   
   
 - to allow a single kernel to be run on several boards. 

   Whether this is useful probably depends a lot on your viewpoint. I had
   two audiences in mind when I did it:

    * the kernel developer who has two or more boards, and wants to be able
      to easily swap between them without having to recompile.

    * the novice user who wants to download a binary kernel and run it, in
      the same way as the do for a 'PC', in particular people who want to
      run Linux on a WinCE/PocketPC Handheld PC PDA.

   I suspect the second catagory is now diminishingly small, as ARM and
   MIPS appear to dominate the HPC market, and most Linux/SH users
   are now working on embedded systems or a single very specific platform
   (Dreamcast and the PocketPenguin guys spring to mind). So this just
   leaves the kernel developers.

   Currently I have to support 2 SH4 variants on 5 different boards, so
   having a single kernel which would run on all of them would be great.
   As well as saving a lot of compilation time, it would make it much
   easier to see if a particular behaviour exhibits itself on different
   hardware, without the problem of using a different kernel binary which
   was built with different options, which may in itself affect the
   behaviour.

   Of course there are limitations with the current system, some soluable
   (where memory is) and some probably not (endianness). And there is a
   (very?) small performance penalty, so I would always want to keep the
   option of building a 'specific' rather than a generic kernel.

   So, are my needs so specific that I'm the only person who would use it,
   or would other people - assuming some of the current limitations could
   be fixed?

Personally I think we need to do another purge of the board specific
#ifdef's from C code (some of which I admit to being responsable for),
and if some other #ifdef's could be removed at the same time, so much the
better.

However whether this involves expanding the mach_vec, or just moving them
into header files and Makefiles probably depends on what we want to do about
the generic kernel support. Personally I like it (but then I would!), but it
does need fixing and maintaining, so if nobody is going to use it we should
probably move to a static system, more like ARM, rather then the current
dynamic scheme which is modelled on the Alpha code.

Sorry about the long ramble, I'll let someone else get their oar in now.

Stuart

Re: [linuxsh-dev] Preparing for 2.5

[M. R. B. <mr...@0x...>]

* Greg Banks <gn...@al...> on Fri, Oct 12, 2001:

> 
>   Personally I think the runtime part of the machvec is fairly pointless;
> it could all be compiletime instead.
> 

Good idea.

> 
> >   Should we register linuxsh.org for it as well? 
> 
>   Someone has it.  Ask Niibe-san for the story.
> 

Nope, both linuxsh.org and linuxsh.net are available.  linuxsh.com isn't.

M. R.

Re: [linuxsh-dev] stable SH4 environment

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Oct 12, 2001:

> 
> The patch for GCC has been approved with name change to -mno-implicit-fp.
> 

Is the approved patch going against HEAD or branch?  I couldn't tell from
the e-mail.

If it's HEAD only, I still don't think it's worth it to include it in
arch/sh/Makefile, you should use a conditional that checks the gcc version
instead.  But if it's branch, it shouldn't be a problem, since gcc 3.0.2 is
right around the corner.

I'm not trying to beat a dead horse here, but my point is that people can
still get away with stock 3.0.1 to compile the kernel, and they shouldn't
necessarily be forced to upgrade to HEAD (or 3.0.2) if it's a cosmetic
change.

M. R.

Re: [linuxsh-dev] MR-SHPC PCMCIA bridge.

[David W. <dw...@in...>]

mk...@cr... said:
> I wrote the driver of MR-SHPC for our hardware like Solution Engine.
> The inital developer of the original code is Mr.Kojima. I revised for
> the LinuxSH kernel version 2.4.2 refering the driver of HD64465.It is
> confirmed that my driver supports Modem and IDE cards.

> http://www.crossnet.co.jp/linux-sh/ 

Thank you. It seems to work for me on the SE7709 - it gets card insertion 
IRQs and 'cardctl status' can identify inserted cards correctly, although I 
haven't actually got cardmgr working yet.

Should we add this to the sourceforge CVS tree?



--
dwmw2

[linuxsh-dev] stable SH4 environment

[NIIBE Y. <gn...@m1...>]

On 25th Aug, NIIBE Yutaka wrote:
 > Here's the patch for new tool chain.  Well, I'd like to commit this
 > change, say, a month later, after we test GCC 3.0.
 > 
 > 	* arch/sh/Makefile (CFLAGS): Use -mno-fdiv-divsi.  Don't use
 > 	-m4-nofpu.
 > 
 > Index: arch/sh/Makefile
 > ===================================================================
 > RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v
 > retrieving revision 1.20
 > diff -u -r1.20 Makefile
 > --- arch/sh/Makefile	2001/07/28 04:02:00	1.20
 > +++ arch/sh/Makefile	2001/08/24 22:22:23
 > @@ -46,8 +46,8 @@
 >  AFLAGS		+= -m3
 >  endif
 >  ifdef CONFIG_CPU_SH4
 > -CFLAGS		+= -m4-nofpu
 > -AFLAGS		+= -m4-nofpu
 > +CFLAGS		+= -m4 -mno-fdiv-divsi
 > +AFLAGS		+= -m4 -mno-fdiv-divsi
 >  endif
 >  
 >  #
 > -- 

The patch for GCC has been approved with name change to -mno-implicit-fp.

I'll upload updated patch against GCC 3.0.1.  Then, I'll apply
arch/sh/Makefile change.
-- 

Re: [linuxsh-dev] Preparing for 2.5

[Greg B. <gn...@al...>]

Paul Mundt wrote:
> 
> Just a small note on this.. FTP access has already been disabled, and the
> stuff does indeed need to be moved into the file release system as soon as
> possible. There's really not that much there to worry about, does anyone have
> a list of what needs to be preserved?

  IIRC it was source tarballs and binaries of gcc, binutils and gdb.
All of these are now controlled somewhere else, we could just point
to those websites.  (Or we could do it properly and have tested RPMs
and SRPMs).

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

[linuxsh-dev] CONFIG_MEMORY_SIZE for Solution Engine.

[David W. <dw...@in...>]

I believe that the all the 77x9 Solution Engines have 32MiB of RAM, and the 
775x models have 64MiB. This patch fixes the setting of CONFIG_MEMORY_SIZE 
for those boards. Unless somebody objects, I'll commit it later on today.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.349
diff -u -r1.349 ChangeLog
--- ChangeLog	2001/10/11 09:48:54	1.349
+++ ChangeLog	2001/10/12 12:22:31
@@ -1,3 +1,7 @@
+2001-10-12  David Woodhouse  <dw...@re...>
+
+	* arch/sh/config.in: Set default memory sizes for Solution Engines
+
 2001-10-11  NIIBE Yutaka  <gn...@m1...>
 
 	* Updated to 2.4.12.
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.58
diff -u -r1.58 config.in
--- arch/sh/config.in	2001/09/14 04:32:25	1.58
+++ arch/sh/config.in	2001/10/12 12:09:42
@@ -90,8 +90,17 @@
 fi
 bool 'Little Endian' CONFIG_CPU_LITTLE_ENDIAN
 # Platform-specific memory start and size definitions
-if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" -o "$CONFIG_SH_HP600" = "y" -o \
-     "$CONFIG_SH_BIGSUR" = "y" -o "$CONFIG_SH_7751_SOLUTION_ENGINE" = "y" -o \
+if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" ]; then
+   define_hex CONFIG_MEMORY_START 0c000000
+   define_hex CONFIG_MEMORY_SIZE 02000000
+   define_bool CONFIG_MEMORY_SET y
+fi
+if [ "$CONFIG_SH_7751_SOLUTION_ENGINE" = "y" ]; then
+   define_hex CONFIG_MEMORY_START 0c000000
+   define_hex CONFIG_MEMORY_SIZE 04000000
+   define_bool CONFIG_MEMORY_SET y
+fi
+if [ "$CONFIG_SH_HP600" = "y" -o "$CONFIG_SH_BIGSUR" = "y" -o \
      "$CONFIG_SH_DREAMCAST" = "y" -o "$CONFIG_SH_SH2000" = "y" ]; then
    define_hex CONFIG_MEMORY_START 0c000000
    define_hex CONFIG_MEMORY_SIZE 00400000


--
dwmw2

Re: [linuxsh-dev] Preparing for 2.5

[Greg B. <gn...@al...>]

"M. R. Brown" wrote:
> 
> - SH backend drop-in tree and restructuring. [...]this week I'll be
>   cleaning up the drop-in tree started by Greg and preparing to import it
>   into CVS under a 'linux' module. 

  Good.

>   [...] Once this is done we should *completely* abandon
>   the massive 'kernel' module, since all of the relevant drop-in code will
>   be the linux module anyway.

  Good.

>   [...] Just file a
>   SR at Sourceforge to remove the darn thing :P.

  We also need to do this with the gcc and binutils in CVS at sourceforge,
as they haven't been current in a long while.  I expect sourceforge will be
pleased to get back all that disk space ;-)

  Also, we need to deal with the disappearance of anonymous FTP space
from sourceforge (which is happening very soon now) and instead use
proper software releases.

> - After the 2.4 drop-in tree is in place, I'll start moving files around
>   per the RFC from a few months back.  This will all be done under a
>   seperate 2.5 branch

  I still think you're going to regret it, but I don't have the energy
to argue it anymore.

>   Also, I wanted to start taking a hard look at the current arch-dependent
>   API exposed in the SH backend.  PCI cleanups, the machvec, etc. all need
>   to be worked on.

  Yep.

  Personally I think the runtime part of the machvec is fairly pointless;
it could all be compiletime instead.

> - Website update.  This isn't necessarily my department, but we should have
>   some discussions on what should go and what should be added to the
>   linuxsh.sourceforge.net website.  Is this intended to be the main site
>   for LinuxSH kernel work, userland work, or both?  

  Yes, yes, and yes.  The reality is somewhat less impressive.

>   If so, should we be
>   contacting some of the other SH on Linux sites and getting them involved?

  Please do.  I've been there.

>   Should we register linuxsh.org for it as well? 

  Someone has it.  Ask Niibe-san for the story.

>   Reorganize the
>   "Documents" section, etc.?

  Yes, and fix the "Downloads" section.  I get one or two emails every week
complaining about its brokenness and I don't have time to fix it.

>  Greg, you're the only LinuxSH guy that I know
>   of that does web work, what are some of your ideas?

  Mostly, "I wish had more time to spend on LinuxSH".  If someone
wants to take it over I'll be more than happy to explain anything
they need to know, and help in any way.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

[linuxsh-dev] Preparing for 2.5

[NIIBE Y. <gn...@m1...>]

What I'm doing these weeks:
I believe I have now the stable GCC which can "make bootstrap", lastly.
"make bootstrap" means "make bootstrap" literally.  There has been a bug
to stop that process.  With -O0, large switch statement cannot be compiled
correctly (expor.c and fold-const.c).
I think I found the bug (See gcc-patches for the fix)...

M. R. Brown wrote:
 > Today Linus hinted that 2.5.x is right around the corner.  This is probably
 > a good idea for LinuxSH to decide what's going to happen to the port during
 > the 2.5 cycle.  Here are some of my ideas:
 > 
 > - SH backend drop-in tree and restructuring.  Yes, I know it's been months
 >   since anyone has heard anything from me on this, but this week I'll be
 >   cleaning up the drop-in tree started by Greg and preparing to import it
 >   into CVS under a 'linux' module.  The initial drop-in tree will be
 >   against the 2.4 series.  Once this is done we should *completely* abandon
 >   the massive 'kernel' module, since all of the relevant drop-in code will
 >   be the linux module anyway.  And no, I would've suggested archiving point
 >   releases of the kernel module, but it seems that mainline merges (from
 >   mainline to LinuxSH haven't been tagged for a looong time).  Just file a
 >   SR at Sourceforge to remove the darn thing :P.

Good.

 > - What's up for 2.5?  When I met with NIIBE-san at LWE, he mentioned that
 >   one of the main things he saw for 2.5 was the beginnings of SH5 support.
 >   The SH5 has a dual-addressing mode, so we'll have to start working on
 >   64-bit support for the backend, among other things.  Did anyone else have
 >   agendas for 2.5?  With the new layout/restructuring, hopefully it'll be
 >   a lot easier to add support for new boards and processors.

I was a bit optimistic.  At that time, I expected the development
environment would be available soon to the public.  The real world is
not like I expected.

Situation is different.  As of SH-3/SH-4, it's under control of Hitachi.
For SH-5, it's SuperH, Inc., who is in charge of. 

For SH-5, it seems for me that it's quite difficult to begin the
development.  I think that I can't do at my position.  For now,
there's no publically available development environment, I mean, GCC
and such.  Even the technical manual of SH-5 CPU is not available for
public.

Perhaps, it could be available under NDA with SuperH, Inc.  However,
it is very very very much difficult at my position (public servant) to
sign NDA to specific company.

I won't go the direction to support SH-5, in near future, perhaps never.

I wish someone with experience could join the SH-5 kernel development.
-- 

[linuxsh-dev] Preparing for 2.5

[M. R. B. <mr...@0x...>]

Today Linus hinted that 2.5.x is right around the corner.  This is probably
a good idea for LinuxSH to decide what's going to happen to the port during
the 2.5 cycle.  Here are some of my ideas:

- SH backend drop-in tree and restructuring.  Yes, I know it's been months
  since anyone has heard anything from me on this, but this week I'll be
  cleaning up the drop-in tree started by Greg and preparing to import it
  into CVS under a 'linux' module.  The initial drop-in tree will be
  against the 2.4 series.  Once this is done we should *completely* abandon
  the massive 'kernel' module, since all of the relevant drop-in code will
  be the linux module anyway.  And no, I would've suggested archiving point
  releases of the kernel module, but it seems that mainline merges (from
  mainline to LinuxSH haven't been tagged for a looong time).  Just file a
  SR at Sourceforge to remove the darn thing :P.

- After the 2.4 drop-in tree is in place, I'll start moving files around
  per the RFC from a few months back.  This will all be done under a
  seperate 2.5 branch, 2.4 will continue to be maintained in the same
  module (just tagged against future 2.4 releases).  That is, 2.4 and 2.5
  will coexist in the same module.  This is actually quite easy to do with
  CVS, and I'll be writing a doc to cover it in case someone feels like
  (*cough*) arguing that point.

- What's up for 2.5?  When I met with NIIBE-san at LWE, he mentioned that
  one of the main things he saw for 2.5 was the beginnings of SH5 support.
  The SH5 has a dual-addressing mode, so we'll have to start working on
  64-bit support for the backend, among other things.  Did anyone else have
  agendas for 2.5?  With the new layout/restructuring, hopefully it'll be
  a lot easier to add support for new boards and processors.

  Also, I wanted to start taking a hard look at the current arch-dependent
  API exposed in the SH backend.  PCI cleanups, the machvec, etc. all need
  to be worked on.

- Website update.  This isn't necessarily my department, but we should have
  some discussions on what should go and what should be added to the
  linuxsh.sourceforge.net website.  Is this intended to be the main site
  for LinuxSH kernel work, userland work, or both?  If so, should we be
  contacting some of the other SH on Linux sites and getting them involved?
  Should we register linuxsh.org for it as well?  Reorganize the
  "Documents" section, etc.?  Greg, you're the only LinuxSH guy that I know
  of that does web work, what are some of your ideas?

- Disparate tree syncing.  Once we start working on 2.5 items, we should be
  more aware of some of the other drop-in trees that have an affect on our
  port.  The main one I can think of is the Ruby tree which contains 2.5.x
  input and framebuffer code.  For example, I'm working on a new pvr2fb
  framebuffer for Ruby, and we would want to sync that with our tree, as
  well as any other input/fb items.  The Ruby tree is part of the
  linuxconsole.sf.net project.

Since Greg created an initial drop-in tree (thanks!), I'll be syncing that
against 2.4.12-whatever, and then I'll post to the list when I'm ready to
import the new module.  The 2.5 branch will come soon after that.

M. R.

Re: [linuxsh-dev] Trouble on cvs.sourceforge.net?

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> NIIBE Yutaka wrote:
>  > Then, I'll apply changes of 2.4.11-preX tomorrow.
> 
> I tried to connect cvs.sourceforge.net, but it seems that there's some
> troubles.  I can't connect to that host...

  I just tried it and cvs.linuxsh.sourceforge.net seems to be working
fine now.  They must have fixed whatever was wrong.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

[linuxsh-dev] Trouble on cvs.sourceforge.net?

[NIIBE Y. <gn...@m1...>]

NIIBE Yutaka wrote:
 > Then, I'll apply changes of 2.4.11-preX tomorrow.

I tried to connect cvs.sourceforge.net, but it seems that there's some
troubles.  I can't connect to that host...
-- 

[linuxsh-dev] [PATCH] Don't kill init when OOM

[NIIBE Y. <gn...@m1...>]

Paul Mundt wrote:
 > Just keeping with the trend.. (everyone else is adopting this already)..
 > The attached patch is based off the same change that was done to the PPC
 > code a little bit ago.

OK.  Please go ahead.

Then, I'll apply changes of 2.4.11-preX tomorrow.
-- 

[linuxsh-dev] Re: More .hidden problems/confusion

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

"M. R. Brown" <mr...@0x...> wrote:
> ./table: error while loading shared libraries: /lib/libstdc++.so.4: undefined symbol: __udivsi3_i4
> 
[snip]
> Any ideas?

I see. Sorry, I forgot this problem.
Please regenerate libstdc++-v3/configure in your gcc source
tree or fix libstdc++-v3/configure by hand:

linux-gnu*)
  case $host_cpu in
  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
    lt_cv_deplibs_check_method=pass_all ;;

to

linux-gnu*)
  case $host_cpu in
  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ｜sh[34]*)
    lt_cv_deplibs_check_method=pass_all ;;

and clean/rebuild libstdc++-v3.

I don't include the above difference of libstdc++-v3/configure
in our patch since this file is regeneratable and the true fix
is in libtool.m4 which is in our patch.

	kaz

Re: [linuxsh-dev] Re: More .hidden problems/confusion

[M. R. B. <mr...@0x...>]

* kaz Kojima <kk...@rr...> on Sat, Oct 06, 2001:

> M. R. Brown" <mr...@0x...> wrote:
> > If I back out the portion of kaz's patch that enables hidden, it executes
> > normally.  Can someone point me to a testcase where .hidden actually does
> > something useful?
> 
> It isn't useful but is required. :-) A very artificial example is:
> 
> int f (int x)
> {
>   int j;
>   register long reg0 asm ("%r0") = x;
> 
>   j = 7/reg0;
>   return reg0 + j;
> }
> 
> If you compile it with -O2, you'll get
> 
> f:
>         mov.l   .L2,r1
>         mov     r4,r0
>         mov.l   r14,@-r15
>         mov     r0,r5
>         sts.l   pr,@-r15
>         jsr     @r1
>         mov     #7,r4
>         sts     fpul,r1
>         mov     r15,r14
>         add     r0,r1
>         mov     r1,r0
>         mov     r14,r15
>         lds.l   @r15+,pr
>         rts
>         mov.l   @r15+,r14
> .L3:
>         .align 2
> .L2:
>         .long   __sdivsi3_i4
> 
> Notice that this code assumes that R0 is kept across the call
> of __sdivsi3_i4. If this code is in an executable and the linker
> finds __sdivsi3_i4 from the shared library, linker fixes the
> content at .L2 so to refers PLT for __sdivsi3_i4. But PLT code
> clobbers R0, so the result of f() will be wrong in such case.
> 
> Well, I don't use gcc-3.0.1 from ftp.m17n.org/pub/super-h/testing
> (Sorry, I'm a 3.1 user :-)), but
> 

Ok, I'm currently using gcc-3.1 (20011006) with your patches.  I still have
problems at runtime when executing apps that have been linked against
libstdc++:

./table: error while loading shared libraries: /lib/libstdc++.so.4: undefined symbol: __udivsi3_i4

So whereas I'm no longer confused about what .hidden *intends* to
accomplish, it still doesn't do what it's supposed to do.

The above is from running a Qt/Embedded example, QtE is built entirely
using shared libraries.

If you can tell me why this breaks, or can point me to an interim fix (yes,
I know you've explained .hidden, I understand that, but obviously it
doesn't work in all cases), I'd appreciate it.

Better than that, kaz, what's your setup?  How do you bootstrap gcc, build
glibc, and build the final gcc?  As I've said, I'm using your latest
patches, except with the 

+     %{!symbolic:-lc -lnss_files -lnss_dns -lresolv -lc}}"

removed from gcc/config/linux.h.

Any ideas?

M. R.

[linuxsh-dev] Re: More .hidden problems/confusion

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

M. R. Brown" <mr...@0x...> wrote:
> If I back out the portion of kaz's patch that enables hidden, it executes
> normally.  Can someone point me to a testcase where .hidden actually does
> something useful?

It isn't useful but is required. :-) A very artificial example is:

int f (int x)
{
  int j;
  register long reg0 asm ("%r0") = x;

  j = 7/reg0;
  return reg0 + j;
}

If you compile it with -O2, you'll get

f:
        mov.l   .L2,r1
        mov     r4,r0
        mov.l   r14,@-r15
        mov     r0,r5
        sts.l   pr,@-r15
        jsr     @r1
        mov     #7,r4
        sts     fpul,r1
        mov     r15,r14
        add     r0,r1
        mov     r1,r0
        mov     r14,r15
        lds.l   @r15+,pr
        rts
        mov.l   @r15+,r14
.L3:
        .align 2
.L2:
        .long   __sdivsi3_i4

Notice that this code assumes that R0 is kept across the call
of __sdivsi3_i4. If this code is in an executable and the linker
finds __sdivsi3_i4 from the shared library, linker fixes the
content at .L2 so to refers PLT for __sdivsi3_i4. But PLT code
clobbers R0, so the result of f() will be wrong in such case.

Well, I don't use gcc-3.0.1 from ftp.m17n.org/pub/super-h/testing
(Sorry, I'm a 3.1 user :-)), but

> So far, I've only gotten this with libstdc++ and by looking at the specs
> file, all normal apps/libs link with -libgcc unless -shared or
> -shared-libgcc are explicitly specified.

It seems this is the real problem. It should be like as

*libgcc:
%{shared-libgcc:-lgcc_s%M -lgcc}%{static-libgcc:-lgcc}%{!shared-libgcc:%{!static-libgcc:%{shared:-lgcc_s%M -lgcc}}}%{!shared-libgcc:%{!static-libgcc:%{!shared:-lgcc}}}

in specs. In your successful "not hidden" case, your hello world
executable takes __udivsi3_i4 from the some shared libraries. It's
just lucky. If your executable has integer divs and needs no shared
libs in which have __udivsi3_i4, then you will get again undefined
errors on linking.

> Oh yeah, one more note about the .hidden hack, if it's meant to "hide"
> routines for shared libraries, it's implementors seemed to forget that the
>majority of libgcc functinality is in gcc/libgcc2.c, and none of those
>routines are "hidden".  There's gotta be a better work around than the
>hidden hack, esp. since SH is the only arch that uses it.

It hides these routines linked in the shared libs *from* the other
shared libs and executables by changing these functions into static
in the shared libs.

The problem never occurs for the functions in libgcc2.c. It occurs
only for the functions in lib1funcs.asm which are treated specially
in gcc. See config/sh/sh.md. Then you can see gcc uses the special
calling RTLs for the calls for some of these functions, so as to
reduce the clobbered registers which can be predictable on these
hand-written functions. Please recall the arguments about this issue.
Of course, the other solution is to add more clobber statements to
these RTLs which aren't required for the static linked cases.
This was my old work around as I wrote. A clear demerit of this way
is that the call via PLT is not so efficient.

	kaz

[linuxsh-dev] [PATCH] Don't kill init when OOM

[Paul M. <pm...@mv...>]

Hello,

Just keeping with the trend.. (everyone else is adopting this already)..
The attached patch is based off the same change that was done to the PPC
code a little bit ago.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Index: ChangeLog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.346
diff -u -r1.346 ChangeLog
--- ChangeLog	2001/10/01 06:16:39	1.346
+++ ChangeLog	2001/10/05 18:47:28
@@ -1,3 +1,8 @@
+2001-10-04  Paul Mundt  <le...@ch...>
+
+	* arch/sh/mm/fault.c (do_page_fault): Don't kill init when out
+	of memory.
+
 2001-10-01  M. R. Brown  <mr...@0x...>
=20
 	* drivers/video/pvr2fb.c (pvr2fb_init): Make fb_find_mode() default
Index: arch/sh/mm/fault.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.48
diff -u -r1.48 fault.c
--- arch/sh/mm/fault.c	2001/08/09 00:27:04	1.48
+++ arch/sh/mm/fault.c	2001/10/05 18:47:41
@@ -134,6 +134,7 @@
 	 * make sure we exit gracefully rather than endlessly redo
 	 * the fault.
 	 */
+survive:
 	switch (handle_mm_fault(mm, vma, address, writeaccess)) {
 	case 1:
 		tsk->min_flt++;
@@ -205,6 +206,12 @@
  */
 out_of_memory:
 	up_read(&mm->mmap_sem);
+	if (current->pid =3D=3D 1) {
+		current->policy |=3D SCHED_YIELD;
+		schedule();
+		down_read(&mm->mmap_sem);
+		goto survive;
+	}
 	printk("VM: killing process %s\n", tsk->comm);
 	if (user_mode(regs))
 		do_exit(SIGKILL);

[linuxsh-dev] More .hidden problems/confusion

[M. R. B. <mr...@0x...>]

.hidden doesn't work with libstdc++.  For example, if I compile and link a
simple C++ program using unsigned integer division:

#include <stdio.h>

int main(void) {
	unsigned int a, b, c;

	printf("Hello, world\n");

	a = 4; b = 4;
	c = a / b;

	return --c;
}

I get an undefined reference to __udivsi3_i4 at runtime when using the
default shared libraries.

If I back out the portion of kaz's patch that enables hidden, it executes
normally.  Can someone point me to a testcase where .hidden actually does
something useful?

So far, I've only gotten this with libstdc++ and by looking at the specs
file, all normal apps/libs link with -libgcc unless -shared or
-shared-libgcc are explicitly specified.

Oh yeah, one more note about the .hidden hack, if it's meant to "hide"
routines for shared libraries, it's implementors seemed to forget that the
majority of libgcc functinality is in gcc/libgcc2.c, and none of those
routines are "hidden".  There's gotta be a better work around than the
hidden hack, esp. since SH is the only arch that uses it.

On an unrelated note, has anyone had any problems including the std C++
headers in programs?  I get a bunch of `undefined' errors from the include
files in bits/.

I'm using the tools provided at ftp.m17n.org/pub/super-h/testing
(binutils-2.11.2 + patches, gcc-3.0.1 + patches, glibc-2.2.4 + patches).

M. R.

RE: [linuxsh-dev] [linux-sh:01958] GCC 3.0.1 compiler seg fault

[Dustin M. <du...@se...>]

Thanks! The new patch works great.

Dustin.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of NIIBE
Yutaka
Sent: Tuesday, October 02, 2001 12:35 AM
To: Dustin McIntire; Linuxsh-Dev; Linux-Sh
Subject: [linuxsh-dev] [linux-sh:01958] GCC 3.0.1 compiler seg fault


For current snapshot of GCC 3.0 branch I cannot reproduce the problem.
Here's a just a work around.

--- gcc-sh-linux-3.0.1.orig/gcc/config/sh/sh.c
+++ gcc-sh-linux-3.0.1/gcc/config/sh/sh.c
@@ -2810,7 +2810,8 @@
   if (! invert_jump (insn, label, 1))
     abort ();
   /* Prevent reorg from undoing our splits.  */
-  gen_block_redirect (jump, bp->address += 2, 2);
+  if (!returnjump_p (jump))
+    gen_block_redirect (jump, bp->address += 2, 2);
 }
 
 /* Fix up ADDR_DIFF_VECs.  */
-- 

_______________________________________________
linuxsh-dev mailing list
lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

[linuxsh-dev] [linux-sh:01958] GCC 3.0.1 compiler seg fault

[NIIBE Y. <gn...@m1...>]

For current snapshot of GCC 3.0 branch I cannot reproduce the problem.
Here's a just a work around.

--- gcc-sh-linux-3.0.1.orig/gcc/config/sh/sh.c
+++ gcc-sh-linux-3.0.1/gcc/config/sh/sh.c
@@ -2810,7 +2810,8 @@
   if (! invert_jump (insn, label, 1))
     abort ();
   /* Prevent reorg from undoing our splits.  */
-  gen_block_redirect (jump, bp->address += 2, 2);
+  if (!returnjump_p (jump))
+    gen_block_redirect (jump, bp->address += 2, 2);
 }
 
 /* Fix up ADDR_DIFF_VECs.  */
-- 

Re: [linuxsh-dev] pvr2fb changes in 2.4.10

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Tue, Oct 02, 2001:

> 
> This part is my mistake.  Sorry.  I've put this for my demonstration
> for LC2001 Japan, and mistakenly committed.
> 
> 
> I apologize, I didn't intend to change it.  I needed some sleep and be
> careful.  Thanks for pointing this out.

Just so you know, you can set the default bpp using the video kernel
commandline parameter, i.e. `video=pvr2fb:640x480-32`.

We're still working on revamping the pvr2fb driver, and also about to start
work on a new pvr2 framebuffer for Ruby.

M. R.

[linuxsh-dev] [linux-sh:01957] GCC 3.0.1 compiler seg fault

[NIIBE Y. <gn...@m1...>]

Dustin McIntire wrote:
 > I've just started using gcc-3.0.1 to build the 2.4.10 kernel, but when I add
 > the cs4281 sound module to the build I get a compiler seg fault. Can anyone
 > else reproduce this?

I can.  I'll look into this.
-- 

[linuxsh-dev] pvr2fb changes in 2.4.10

[NIIBE Y. <gn...@m1...>]

M. R. Brown wrote:
 > Uh, did the following changes come from mainline?  The fb_find_mode()
 > portion was discussed already, and it's wrong so I'm backing it out.

This part is my mistake.  Sorry.  I've put this for my demonstration
for LC2001 Japan, and mistakenly committed.

 > @@ -1047,7 +1047,7 @@
 >  		defmode = DEFMODE_VGA;
 >  
 >  	if (!fb_find_mode(&var, &fb_info, mode_option, pvr2_modedb,
 > -	                  NUM_TOTAL_MODES, &pvr2_modedb[defmode], 16)) {
 > +	                  NUM_TOTAL_MODES, &pvr2_modedb[defmode], 32)) {
 >  		return -EINVAL;
 >  	}

Other parts are from mainline.  You can find the change in the
patch-2.4.10.bz2.  I don't know from where it comes.

 > I hope we aren't sneaking subtle changes in and not logging/posting them.
 > Especially if it's in code that doesn't belong to you...

I apologize, I didn't intend to change it.  I needed some sleep and be
careful.  Thanks for pointing this out.
-- 

Re: [linuxsh-dev] Crashme!!!

[M. R. B. <mr...@0x...>]

* Bao C. Ha <ba...@se...> on Wed, Sep 26, 2001:

> 
> The purpose of crashme is to test the  operating environment's 
> robustness  by  invoking random data as if it were a procedure.
> The standard signals are caught and  handled  with  a  setjmp 
> back to a loop which will try again to produce a fault by 
> executing random data.
> 

Check out the Linux Test Project, it's designed to test multiple areas of
the kernel, and it may help you pinpoint the exact points of failure in
these kernels.

http://ltp.sf.net/

M. R.