[parisc-linux] PA8000 modutils problems

M. Grabert xam@cs.ucc.ie
Fri, 21 Jun 2002 23:51:01 +0100 (IST)


On Fri, 21 Jun 2002, John David Anglin wrote:

> > I tried pa35 (32bit), which caused unaligned address traps during boot
> > (IIRC it was e2fsck).
> > I rebooted with pa20, which worked (but has the known IO problems,
> > i.e. copying a full CD to hard disk with lock up the machine).
> > Later I tried compiling pa39 (32bit), but depmod reported
> > "unhandled relocation of type 74" for each function in each module.
> > Compiling 64bit with the (quite old) unofficial debs worked however,
> > but there are some "unresolved symbols" in a few (=4) modules,
> > each time the symbol is "__xchg64". I'm quite sure that in former times
> > all modules worked. Since these modules are not important to me
> > (smbfs and some ipv6 netfilter modules) there is no hurry ;)

I think the unsresolve symbols are just simple programmers bugs which
will 'autmagically' be fixed in later kernels. At least this happened to
me quite a few times (on different platforms, different kernels & modules)

> Depmod does it own limited handling of relocations.  You probably
> need to stick with the recommended compiler (debian 3.0.4 and binutils)
> to be compatible with the relocation capability of depmod.  The
> alignment issues also are likely a result of using 3.1.  BIGGEST_ALIGNMENT
> was changed last Feb. to 128 bits to allow struct alignment suitable
> for the ldcw semaphore insn.  I believe the deb version of gcc was
> patched to do this as well.

I forgot to mention that I used 'gcc' (thus 3.0) to compile -pa39
(32bit, and 'hppa64-gcc' for 64bit). I'm quite sure about that.

However I'm have to agree that I used gcc-3.1 for the not
correctly working -pa35 (unaligned address). That's the reason why
I chose to use the default gcc for compiling -pa39!

Therefore the depmod issue is IMHO due to some other error ...

> Now, there is a known issue with PA2.0 code generation.  It affects
> floating point loads from symbolic memory locations using the 32-bit
> elf tools.  As a result, the code generation default is still PA1.1.
> I'm planning to change this to PA2.0 for PA2.0 machines when the
> assembler bug is fixed.

So what is the point in choosing the PA8000 anyway ? ;)
Oh, I forgot; to be able to select 64bit kernel!

Thanks alot for the quick answer!

Greeting max

-- 
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.