[parisc-linux] [MERGE] -pre8 merge status

[parisc-linux] [MERGE] -pre8 merge status

[Grant Grundler]

Hi all,
kernel now compiles with default .config but dies in the linker with:

hppa1.1-linux-ld  -T /linux/grundler/linux-2.3/arch/parisc/vmlinux.lds  arch/parisc/real/head.o  init/main.o init/version.o \
        --start-group \
        arch/parisc/kernel/pdc_cons.o arch/parisc/kernel/process.o arch/parisc/real/real.o /linux/grundler/linux-2.3/arch/parisc/lib/lib.a arch/parisc/mm/mm.o arch/parisc/kernel/kernel.o arch/parisc/hpux/hpux.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/parisc/kernel/init_task.o \
        drivers/block/block.a drivers/char/char.o drivers/net/net.o  drivers/pci/pci.a drivers/gsc/gsc.a \
        net/network.a \
        /linux/grundler/linux-2.3/arch/parisc/lib/lib.a /linux/grundler/linux-2.3/lib/lib.a  \
        --end-group \
        -o vmlinux
mm/mm.o: In function `L1575':
mm/mm.o(.text+0x15ec): undefined reference to `clear_user_page'
fs/fs.o: In function `set_fs_altroot':
fs/fs.o(.text+0x11a98): undefined reference to `__emul_prefix'
fs/fs.o: In function `L1184':
fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
ipc/ipc.o: In function `L1833':
ipc/ipc.o(.text+0x7088): undefined reference to `clear_user_page'
net/network.a(sunrpc.o): In function `rpc_create_client':
sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
make: *** [vmlinux] Error 1

Thanks to all who helped!

later,
grant

Re: [parisc-linux] [MERGE] -pre8 merge status

[Philipp Rumpf]

> > fs/fs.o: In function `L1184':
> > fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> > net/network.a(sunrpc.o): In function `rpc_create_client':
> > sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
> 
> can't see why you're having trouble here.  those variables are defined in
> net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
> up here so I can try to reproduce.  [Dead hard drives SUCK].

grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
explain your problems.

Re: [parisc-linux] [MERGE] -pre8 merge status

[Philipp Rumpf]

> grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
> explain your problems.

Okay, by the look of things RPC_DEBUG doesn't make sense if you don't
have CONFIG_SYSCTL too.  RPC_DEBUG always gets defined in current 2.3
versions, and presumably will be undefined in a stable kernel version.

I wouldn't really consider this a bug, but if anyone does he should
probably report it to whoever is working on that code in 2.3.

	Philipp Rumpf

Re: [parisc-linux] [MERGE] -pre8 merge status

[willy]

On Fri, May 26, 2000 at 04:26:35PM -0700, Grant Grundler wrote:
> mm/mm.o: In function `L1575':
> mm/mm.o(.text+0x15ec): undefined reference to `clear_user_page'
> ipc/ipc.o: In function `L1833':
> ipc/ipc.o(.text+0x7088): undefined reference to `clear_user_page'

fixed.

> fs/fs.o: In function `set_fs_altroot':
> fs/fs.o(.text+0x11a98): undefined reference to `__emul_prefix'

fixed.

> fs/fs.o: In function `L1184':
> fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> net/network.a(sunrpc.o): In function `rpc_create_client':
> sunrpc.o(.text+0x360): undefined reference to `rpc_debug'

can't see why you're having trouble here.  those variables are defined in
net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
up here so I can try to reproduce.  [Dead hard drives SUCK].

> make: *** [vmlinux] Error 1
> 
> Thanks to all who helped!

Yes, thanks to everyone!  I'd prefer if people still didn't commit until
we lay down a tag signifying end-of-merge.

Re: [parisc-linux] [MERGE] -pre8 merge status

[willy]

On Fri, May 26, 2000 at 08:45:22PM -0600, Philipp Rumpf wrote:
> > > fs/fs.o: In function `L1184':
> > > fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> > > net/network.a(sunrpc.o): In function `rpc_create_client':
> > > sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
> > 
> > can't see why you're having trouble here.  those variables are defined in
> > net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
> > up here so I can try to reproduce.  [Dead hard drives SUCK].
> 
> grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
> explain your problems.

I think that's the case.  It's disabled by default if you make oldconfig,
so I'll commit a new defconfig which has it enabled (and has some of
the new options predefined).

I'm hitting an undefined __shrdiv3 (or something... lost that error
message, but it's one of those gcc-wants-64-bit-ops symbols).

Re: [parisc-linux] [MERGE] -pre8 merge status

[Alan Modra]

On Sat, 27 May 2000 willy@thepuffingroup.com wrote:

> __lshrdi3.  It's referenced from fs/nfs/inode.c.  I'm damned if I can
> see where though (and I went through the gcc -E output trying to spot it.)

You won't spot it that way.  You need to look at the output of gcc -S.
It's likely from some long long arithmetic somewhere.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] [MERGE] -pre8 merge status

[willy]

On Sat, May 27, 2000 at 12:08:05AM -0400, willy@thepuffingroup.com wrote:
> On Fri, May 26, 2000 at 08:45:22PM -0600, Philipp Rumpf wrote:
> > > > fs/fs.o: In function `L1184':
> > > > fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> > > > net/network.a(sunrpc.o): In function `rpc_create_client':
> > > > sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
> > > 
> > > can't see why you're having trouble here.  those variables are defined in
> > > net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
> > > up here so I can try to reproduce.  [Dead hard drives SUCK].
> > 
> > grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
> > explain your problems.
> 
> I think that's the case.  It's disabled by default if you make oldconfig,
> so I'll commit a new defconfig which has it enabled (and has some of
> the new options predefined).

Um.  That's definitely bad since then we don't have a sysrq_enabled definition.
(it's in drivers/char/keyboard.c which we don't use).  But now I've changed
it to `N', make dep, make clean, make vmlinux and I don't get those undefined
symbols.  Curioser and curioser.  My .config was generated from `make oldconfig'
with just hitting return for new options (ie answering `no').

> I'm hitting an undefined __shrdiv3 (or something... lost that error
> message, but it's one of those gcc-wants-64-bit-ops symbols).

__lshrdi3.  It's referenced from fs/nfs/inode.c.  I'm damned if I can
see where though (and I went through the gcc -E output trying to spot it.)
Does someone want to copy that from libgcc?  I'm going to lay down a tag
for end-of-merge now since I'm headed off for the weekend.

Re: [parisc-linux] [MERGE] -pre8 merge status

[John David Anglin]

> __lshrdi3.  It's referenced from fs/nfs/inode.c.  I'm damned if I can
> see where though (and I went through the gcc -E output trying to spot it.)
> Does someone want to copy that from libgcc?  I'm going to lay down a tag
> for end-of-merge now since I'm headed off for the weekend.

__lshrdi3 should be in libgcc.a.  It's in mine.  If it is not there, you
have a problem building your (cross-)compiler.  If it is, check the link
by adding "-v" to the gcc link operation to see why libgcc.a is not being
linked into the object.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] [MERGE] -pre8 merge status

[Philipp Rumpf]

On Sat, May 27, 2000 at 12:08:05AM -0400, willy@thepuffingroup.com wrote:
> On Fri, May 26, 2000 at 08:45:22PM -0600, Philipp Rumpf wrote:
> > > > fs/fs.o: In function `L1184':
> > > > fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> > > > net/network.a(sunrpc.o): In function `rpc_create_client':
> > > > sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
> > > 
> > > can't see why you're having trouble here.  those variables are defined in
> > > net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
> > > up here so I can try to reproduce.  [Dead hard drives SUCK].
> > 
> > grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
> > explain your problems.
> 
> I think that's the case.  It's disabled by default if you make oldconfig,
> so I'll commit a new defconfig which has it enabled (and has some of
> the new options predefined).
> 
> I'm hitting an undefined __shrdiv3 (or something... lost that error
> message, but it's one of those gcc-wants-64-bit-ops symbols).

lshrdi3 ?  that should be supplied in arch/parisc/lib but isn't.

if it has mul in it, maybe the nfs code wasn't fixed not to use 64-bit
multiplies.  a rather hacky fix for that would be

+++ linux/fs/nfs/nfs2xdr.c      Sun May 14 03:31:27 2000
@@ -658,9 +658,9 @@
        res->maxfilesize = 0x7FFFFFFF;  /* just a guess */
        res->bsize  = ntohl(*p++);
 
-       res->tbytes = ntohl(*p++) * res->bsize;
-       res->fbytes = ntohl(*p++) * res->bsize;
-       res->abytes = ntohl(*p++) * res->bsize;
+       res->tbytes = ntohl(*p++) * ((u32)res->bsize);
+       res->fbytes = ntohl(*p++) * ((u32)res->bsize);
+       res->abytes = ntohl(*p++) * ((u32)res->bsize);
        res->tfiles = 0;
        res->ffiles = 0;
        res->afiles = 0;

but istr it was discussed on l-k and fixed.

Sigh.  Is it really fun for you to run into the very same problems I
had while merging with 2.3.99-pre6 ?

	Philipp Rumpf

Re: [parisc-linux] [MERGE] -pre8 merge status

[Philipp Rumpf]

On Sat, May 27, 2000 at 12:56:46AM -0400, willy@thepuffingroup.com wrote:
> On Sat, May 27, 2000 at 12:08:05AM -0400, willy@thepuffingroup.com wrote:
> > On Fri, May 26, 2000 at 08:45:22PM -0600, Philipp Rumpf wrote:
> > > > > fs/fs.o: In function `L1184':
> > > > > fs/fs.o(.text.init+0x18fc): undefined reference to `nfs_debug'
> > > > > net/network.a(sunrpc.o): In function `rpc_create_client':
> > > > > sunrpc.o(.text+0x360): undefined reference to `rpc_debug'
> > > > 
> > > > can't see why you're having trouble here.  those variables are defined in
> > > > net/sunrpc/sysctl.c.  is that file being built?  i'm getting a toolchain
> > > > up here so I can try to reproduce.  [Dead hard drives SUCK].
> > > 
> > > grant: did you have CONFIG_SYSCTL set ?  if you didn't, that might
> > > explain your problems.
> > 
> > I think that's the case.  It's disabled by default if you make oldconfig,
> > so I'll commit a new defconfig which has it enabled (and has some of
> > the new options predefined).
> 
> Um.  That's definitely bad since then we don't have a sysrq_enabled definition.
> (it's in drivers/char/keyboard.c which we don't use).  But now I've changed
> it to `N', make dep, make clean, make vmlinux and I don't get those undefined
> symbols.  Curioser and curioser.  My .config was generated from `make oldconfig'
> with just hitting return for new options (ie answering `no').
> 
> > I'm hitting an undefined __shrdiv3 (or something... lost that error
> > message, but it's one of those gcc-wants-64-bit-ops symbols).
> 
> __lshrdi3.  It's referenced from fs/nfs/inode.c.  I'm damned if I can
> see where though (and I went through the gcc -E output trying to spot it.)

it's Logical SHift Right DI (i.e. 8 byte).  I.e. somethnig like

u64 foo, bar;

bar = foo >> 7;

if you do s/u64/s64/ in the example, it would generate a call to __ashrdi3,
which we have code in arch/parisc/lib/ashrdi3.c for.  Now look at m68k.
They have code for lshrdi3 in the same place as for ashrdi3.  So, it would
be logical for us to do the same, and I have, in my tree, a few weeks ago
</hint>.
	
	Philipp Rumpf

Re: [parisc-linux] [MERGE] -pre8 merge status

[Philipp Rumpf]

On Sat, May 27, 2000 at 11:31:08AM -0400, John David Anglin wrote:
> > __lshrdi3.  It's referenced from fs/nfs/inode.c.  I'm damned if I can
> > see where though (and I went through the gcc -E output trying to spot it.)
> > Does someone want to copy that from libgcc?  I'm going to lay down a tag
> > for end-of-merge now since I'm headed off for the weekend.
> __lshrdi3 should be in libgcc.a.  It's in mine.  If it is not there, you
> have a problem building your (cross-)compiler.  If it is, check the link
> by adding "-v" to the gcc link operation to see why libgcc.a is not being
> linked into the object.

Our kernel doesn't get linked with libgcc;  I don't think it's worth it to
move to using libgcc.a now, even though some architectures do use it.

	Philipp Rumpf