----------------------------------------------------------------------
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 ***************** -------