> I am trying to create a 64 bit driver on Solaris 8
> If I use cc compiler with options "-xarch=v9 -xregs=no%appl", then I am
> able to successfully create the driver, add and attach it to the system
Most people recommend the Sun cc compiler. I _have_ written Solaris
drivers using gcc (32-bit). But I did encounter a "gotcha" or two.
> But if I use gcc compiler with options
> "-mcpu=v9 -mtune=ultrasparc -m64 -mno-app-regs", I am able to create the
> driver. But on loading the driver using add_drv, it bombs.
> if I do "dmesg", I am getting the following errors:
> May 1 15:17:18 ipksun09 krtld: [ID 995402 kern.notice]
> /usr/kernel/drv/sparcv9/oe: undefined symbol 'memcpy'
This is one of the gotchas. A driver is a relocatable object module
which is dynamically linked with the kernel. Thus, the only external
references that are permitted are those defined in the kernel. The
kernel defines printf(), so you can use it -- but its internals are
very different from the one in libc. The kernel does _not_ define
memcpy, so you can't use it!!! It does define the similar routine
bcopy(), which you can use.
Unfortunately, you may not have called memcpy yourself -- it may have
been generated by gcc, e.g. to copy one structure to another. If that
is the case, you have to figure out an alternate way of doing things
that does not generate the reference, or else include your own
definition of memcpy().
> May 1 15:17:18 ipksun09 krtld: [ID 472681 kern.notice] WARNING: mod_load:
> cannot load module 'oe'
> May be, I am not using the correct combination of the gcc SPARC machine
> dependent options.
> Any idea how to fix this ??
It's best to use the Sun compiler if you can. If you _must_ use gcc,
be prepared to learn more than you ever wanted to know about the SPARC
assembly code generated by gcc. And expect driver development to take
at least twice as long as you think it should.
> Kirti Khandelwal
> Infosys Technologies Ltd.
Joseph Reuter, Wizard-in-Training