Re: [linuxsh-dev] Today's addition

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

Hello Pierre!

Thanks for your feedback.

(1) RAMDISK issue

I'll try that.  Thanks.

(2) Initialization of SCI

I think that this issue is resolved in current kernel (2.3.99-pre6 and
later).  If not, please let us know.

(3) Peripheral clock

 > Ideally, I think it'd be good to have an option in the .config to
 > set the bus clock speed and have several tables defined and
 > selected with #ifdefs.

Yes, that'd be a solution.  Alternatively, we could use the value
measured with RTC.  I'm thinking exporting the variable
sh_periheral_clock and sh_module_clock from time.c.  I know that
current code of time.c is not correct for all the cases, but it works
at least for me.

 > I don't know if any of the above will help anyone but I thought I
 > might share my findings.

Surely, it helps much.  Thank you.

 > Now for the plea for help :-) :

Yes.  Welcome to the development team!!

 > I assume everybody on the list has userland programs compiled
 > dynamically and running good on their boards. For some reason, I
 > can run programs that have been compiled statically against glibc
 > just fine, but I can't run dynamically linked programs because
 > ld.so segfaults (I use Kaz' latest patch for glibc). What happens
 > is that ld.so starts, and eventually the function
 > elf_machine_rela() (in sysdeps/sh/sh3/dl-machine.h) is called
 > during the initial relocation from _dl_start() and the segfault
 > occurs when the code tries (I think) to poke a fixed-up address in
 > the code section (which is read-only) instead of the GOT (which is
 > read-write).

Your description is correct.  I guess that the target label to be
resolved is the one of libgcc.a, isn't it?  Here is the story.

----------------
(a) Libgcc is the library of functions which GCC assumes.  In the case
    of SuperH, division results the function call to libgcc, for
    example.

(b) ld.so is the dynamic loader, it could not depends on other
    libraries, by definition (since it *is* the first entity to be
    loaded and it load other libraries).

(c) In the current setting of GCC and GNU Binutils, there's no
    difference between libgcc and other libraries.  The linker handles
    libgcc as just a library.

[... I forgot the detail, I'll explain later if needed ...]

(z) In the current building process of GNU C library, we unfortunately
    have relocation entries for libgcc.
----------------

There'd be many ways to resolve this issue.  Say, having libgcc shared
library, changing GNU C library building process, and so on.  My trial
is changing GCC so that we can distingush the label of libgcc
functions.  Please get the patch from:
	ftp://ftp.m17n.org/pub/super-h/gcc-symbol-vis-000501.diff.gz

It's agains the Kaz' patch of gcc-2.95.2-000228.

WARNING: This is just a experimental hack.  This may not included
standard distribution of GCC, since I did this hack without seeing the
proposed-but-not-yet-released gABI, guess(and expect)ing the feature.

With this patch, you don't see the entries on ld.so.  Again, this may
be work around, not the solution.  We have to think hard, more...

Please let me know how this works (or not) for you, if you will try.
-- 
Niibe Yutaka