[parisc-linux] undefined reference in libgcc.a

[parisc-linux] undefined reference in libgcc.a

[blacky]

hiya all,

I've been trying to make a parisc-linux crosscompiler from a
i586-linux-gnu platform, the binutils build with no problems, but
at the final stage of building gcc it stops at the libgcc-test
with the following error :

libgcc1-test.o: In function `main_without__main':
/home/blacky/cvs/build/gcc/../../gcc/gcc/libgcc1-test.c:20: undefined reference to `$global$'

it seems to reference to the integer-divide function in libgcc.

How can I get around this problem ?

thanx in advance,

Signed, Marco van den Heuvel

Re: [parisc-linux] undefined reference in libgcc.a

[Philipp Rumpf]

> I've been trying to make a parisc-linux crosscompiler from a
> i586-linux-gnu platform, the binutils build with no problems, but
> at the final stage of building gcc it stops at the libgcc-test
> with the following error :
> 
> libgcc1-test.o: In function `main_without__main':
> /home/blacky/cvs/build/gcc/../../gcc/gcc/libgcc1-test.c:20: undefined reference to `$global$'
> 
> it seems to reference to the integer-divide function in libgcc.
> 
> How can I get around this problem ?

The Easy Way:  remove the rule to build libgcc1-test out of the gcc Makefile.

AIUI, the right way would be to supply a crt1.o (or similar) that defines
$global$, _start aso.

	Philipp Rumpf

[parisc-linux] HIL_BASE ("finding" devices)

[Brian S. Julin]

Hi,

I've only just really started to hack at the HIL driver, but
one thing I noticed off the bat is that the HIL_BASE defined
in hil.h is 0xf0821000 while the device base listed when 
I boot for the HIL is 0xf0201000.  This probably means it 
varies across different models.

Optimally I suppose the best thing would be to somehow 
find the device -- the code that prints out the hardware 
found seems to get strings from the "pdc" which I glean is
the "BIOS".  I suppose the only thing the HIL will have that
is unique is this string, or are there model invariant 
numbers like the PCI fn?  (I haven't been through every 
entry in the hardware database to see.)  Basically I'm
asking is there a better way than a strcmp on the pdc string?

Alternatively I suppose we could do what the alpha folk
have done and have a compile-time selection of the system type
(e.g. "avanti") which sets the values for various things like that.

--
Brian S. Julin

Re: [parisc-linux] HIL_BASE ("finding" devices)

[Philipp Rumpf]

On Sun, Mar 12, 2000 at 03:52:52PM -0500, Brian S. Julin wrote:
> I've only just really started to hack at the HIL driver, but
> one thing I noticed off the bat is that the HIL_BASE defined
> in hil.h is 0xf0821000 while the device base listed when 
> I boot for the HIL is 0xf0201000.  This probably means it 
> varies across different models.

It probably does.   AFAIK, the HIL driver is pretty much a hack
Matthew did to get his 715's keyboard working (the 715 and keyboard
are here now and Matthew is in Ottawa, and I don't have it set up
so didn't work on the driver).

> Optimally I suppose the best thing would be to somehow 
> find the device -- the code that prints out the hardware 
> found seems to get strings from the "pdc" which I glean is
> the "BIOS".  I suppose the only thing the HIL will have that
> is unique is this string, or are there model invariant 
> numbers like the PCI fn?

There are indeed, hversion and sversion are the words you're looking
for.  See the register_driver for the current (broken IMHO) interface.

> Alternatively I suppose we could do what the alpha folk
> have done and have a compile-time selection of the system type
> (e.g. "avanti") which sets the values for various things like that.

No way.  The "machine vector" concept wouldn't work well for us - it
works for ppc and alpha because those machines usually have a relatively
limited number of setups - with most chipsets, you can only use one CPU
type;  Lasi is used with PA7100LC, PA7300LC, PA8000, PA8200, and PA8500,
and shares code with the PA7100 (?) version (ASP) as well.  Furthermore
PDC device detection is sane to a certain extent - a lot of devices PDC
doesn't tell us about though.

	Philipp Rumpf