[6274] in www-talk@info.cern.ch
Linux-Activists - GCC Channel digest. 94-9-20-16:5
daemon@ATHENA.MIT.EDU (Linux Activists)
Fri Oct 21 01:42:38 1994
Date: Fri, 21 Oct 1994 06:41:07 +0100
Errors-To: postmaster@www0.cern.ch
Errors-To: postmaster@www0.cern.ch
Reply-To: linux-activists@niksula.hut.fi
From: "Linux Activists" <linux-activists@niksula.hut.fi>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Topics:
Re: Linux-Activists - GCC Channel digest. 94-9-19-6:33
All Elf? (no!)
What's broken here (building xf86 on elf)
Pentium support in GCC
address space segmentation
----------------------------------------------------------------------
From: Daniel Barlow <jo95004@sable.ox.ac.uk>
Subject: Re: Linux-Activists - GCC Channel digest. 94-9-19-6:33
Date: Thu, 20 Oct 1994 11:53:02 +0200
> Question: is there anything left in Linux that requires non-ELF
>binaries. In particular, do we still need non-ELF binaries to build:
>
> (a) the kernel, and
> (b) dynamicly loadable libraries for the Andrew system.
Don't know, but what about dosemu? It needs changing at least ...
AFAICR, the current procedure is to write most of it as a library
starting at .5Gb, then have a small loader program that jumps to it
Daniel
------------------------------
From: Byron Thomas Faber <bf11620@coewl.cen.uiuc.edu>
Subject: All Elf? (no!)
Date: Thu, 20 Oct 1994 09:02:26 -0500 (CDT)
Just a note. While we can port alot of applications to Elf, we should
remember the commerical places that sell Motif.
They will yell loudly if we change formats suddenly on them.
If/when we do go all elf, they should all be notified.
Byron Faber
--
Real programmers don't comment their code. It was hard to write, it
should be hard to understand.
b-faber@uiuc.edu & http://www.cen.uiuc.edu/~bf11620
------------------------------
From: araw@iplab.xray.ufl.edu (Robert Moser)
Subject: What's broken here (building xf86 on elf)
Date: Thu, 20 Oct 94 10:45:39 EDT
I have the same errors as before, undefined references that shouldn't be.
I thought perhaps my source tree was corrupt somehow, so I downloaded a fresh
set, patched them, and rebuilt. Same errors. The entire build seems to make--
programs, shared libraries, except for the servers themselves. hj, have
you seen this before?
Output from World.log--
gcc -b i486-linuxelf -o XF86_SVGA -O2 -m486 -ansi -DNO_ASM -L../../usrlib .
./../programs/Xserver/hw/xfree86/common/XF86_SVGA.o ../../programs/Xserver/hw/xf
ree86/vga256/vga256Conf.o ../../programs/Xserver/hw/xfree86/vga256/drivers/libdr
iver256.a ../../programs/Xserver/hw/xfree86/vga256/libvga256.a ..
/../programs/Xserver/hw/xfree86/common/xf86Init.o ../../programs/Xserver/hw/xfre
e86/common/xf86_Option.o ../../programs/Xserver/hw/xfree86/common/libxf86.a ../.
./programs/Xserver/hw/xfree86/common_hw/libxf86_hw.a ../../programs/Xserver/hw/x
free86/os-support/libxf86_os.a dix/libdix.a os/libos.a ../../lib/Xau/libXau.a ..
/../lib/Xdmcp/libXdmcp.a ../../usrlib/libfont.a cfb/libcfb.a cfb16/libcfb.a cfb3
2/libcfb.a mfb/libmfb.a mi/libmi.a Xext/libext.a XIE/dixie/libdixie.a XIE/mixi
e/libmixie.a PEX5/dipex/dispatch/libdidipex.a PEX5/dipex/swa
p/libdiswapex.a PEX5/dipex/objects/libdiobpex.a
PEX5/dipex/dispatch/libdidipex.a PEX5/ddpex/mi/level4/l
ibddpex4.a PEX5/ddpex/mi/level3/libddpex3.a
PEX5/ddpex/mi/shared/libddpexs.a PEX5/ddpex/mi/level2/libdd
pex2.a PEX5/ddpex/mi/level1/libddpex1.a PEX5/
ospex/libospex.a -L/usr/X11R6/lib -lm mi/libcbrt.a -lm
al_drv.o(.data+0x28): undefined reference to `AL2101SetRead'
al_drv.o(.data+0x2c): undefined reference to `AL2101SetWrite'
al_drv.o(.data+0x30): undefined reference to `AL2101SetReadWrite'
ati_drv.o(.text+0xcad): undefined reference to `ATIV3SetRead'
ati_drv.o(.text+0xcb7): undefined reference to `ATIV3SetWrite'
ati_drv.o(.text+0xcc1): undefined reference to `ATIV3SetReadWrite'
ati_drv.o(.text+0xcfa): undefined reference to `ATIV4V5SetRead'
ati_drv.o(.text+0xd04): undefined reference to `ATIV4V5SetWrite'
ati_drv.o(.text+0xd0e): undefined reference to `ATIV4V5SetReadWrite'
ati_drv.o(.text+0x13e2): undefined reference to `ATIB2Reg'
ati_drv.o(.text+0x16cb): undefined reference to `ATIB2Reg'
ati_drv.o(.text+0x1f2a): undefined reference to `_ATIExtReg'
ati_drv.o(.text+0x1f68): undefined reference to `_ATIExtReg'
ati_drv.o(.text+0x1fa2): undefined reference to `_ATIExtReg'
ati_drv.o(.text+0x1fe2): undefined reference to `_ATIExtReg'
ati_drv.o(.text+0x2006): undefined reference to `_ATIExtReg'
ati_drv.o(.text+0x2026): more undefined references to `_ATIExtReg' follow
ati_drv.o(.data+0x28): undefined reference to `ATISetRead'
ati_drv.o(.data+0x2c): undefined reference to `ATISetWrite'
ati_drv.o(.data+0x30): undefined reference to `ATISetReadWrite'
.. the list goes on...
Yet I check al_drv.o--
nm al_drv.o
00000000 D AL2101
000004f0 t AL2101Adjust
00000000 t AL2101ClockSelect
00000290 t AL2101EnterLeave
000000d0 t AL2101Ident
00000460 t AL2101Init
00000100 t AL2101Probe
00000300 t AL2101Restore
000003b0 t AL2101Save
U AL2101SetRead
U AL2101SetReadWrite
U AL2101SetWrite
U NoopDDA
U Num_VGA_IOPorts
U StrCaseCmp
U VGA_IOPorts
0000055c T _AL2101SetRead <----
0000056c T _AL2101SetReadWrite <---- the functions which were missing
00000564 T _AL2101SetWrite <---- in the link
0000011c d chipsets.30
00000000 t gcc2_compiled.
00000000 b save1.26
00000002 b save2.27
U vga256InfoRec
U vgaGetClocks
U vgaHWInit
U vgaHWRestore
U vgaHWSave
U vgaIOBase
U vgaNewVideoState
U xf86AddIOPorts
U xf86ClearIOPortList
U xf86DisableIOPorts
U xf86EnableIOPorts
file al_drv.o
al_drv.o: ELF 32-bit LSB relocatable i386 (386 and up) Version 1
The other 'missing functions' seem to be where they are supposed to be
also. Any ideas? How to proceed from here? Other folks seem to be able
to build everything elf.
System: Kernel 1.1.54, Zeos Pantera P60, 16mb ram, onboard scsi (aha152x
compatible), using libc-4.6.16, gas-941015, gcc-941014.
Robert Moser
------------------------------
From: Karl Keyte <KKEYTE%ESOC@FINHUTC.HUT.FI>
Subject: Pentium support in GCC
Date: Thu, 20 Oct 94 17:25:30 EWT
Does anyone know if there's support (actual or planned) for
Pentium support in the latest (2.6.x) versions of GCC? Something
like:
gcc -m586 ....
?? Would be useful.
Karl
------------------------------------------------------------------------
Vitrociset S.p.A. (Space Division) Tel : +(49) 6151 902041
European Space Operations Centre Fax : +(49) 6151 904041
Darmstadt, Germany e-Mail: kkeyte@esoc.bitnet
------------------------------
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: address space segmentation
Date: Thu, 20 Oct 94 19:42:08 +0100
Dear H.J., Eric and all,
ELF programs apparently call mmap(..., MAP_FIXED, ...) at addresses like
0x4008b000 and 0x8000000. This makes mmap() less useful because it cuts
down the range of available addresses.
Up to now, with a.out, we have the following layout:
0xFFFFFFFF
... kernel space, not available in user mode
0xC0000000
0xBFFFFFFF
... stack, growing downward
0x80000000
0x7FFFFFFF
... shared libraries, usually at 0x6.......
0x60000000
0x5FFFFFFF
... mmap() and shmat() segments with no address specified
0x40000000
0x3FFFFFFF
... free for mmap(MAP_FIXED) and shmat()
~ 0x01000000
... program, data, bss, brk & malloc
0x00000000
mmap(.. MAP_FIXED ..) is useful because the programmer can choose the
address, for example to encode type or protection information in the
high 8 bits of the address. (Lisp and Prolog implementations make use
of this.)
With the current scheme, 95 segments of 16 MB each are available
(0x01..0x5F), with the ability to encode information in 7 bits.
If, with ELF, only the address space 0x10000000..0x3FFFFFFF remains
(what's below 0x08000000 ?), this is restricted to 48 segments of 16 MB each,
with only 6 bits for information.
Can this be avoided?
How about
1. moving the 0x40000000 stuff to 0x70000000,
2. setting the initial brk() value to 0x00800000 instead of 0x08000000 ?
(In fact, USL SVR4/386 uses 0x08000000, Ultrix and Irix use 0x10000000,
AIX uses 0x20000000, HP-UX uses 0x40000000. Are they playing dice?)
I understand that the program's address is stored in the ELF header
field called `vaddr'. Can it be specified as a linker option?
We have 4 GB address space. Look what you make out of it!
Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de
------------------------------
End of GCC Digest
*****************
-------
