Name Date Size #Lines LOC


README.LFSH A D14-Feb-20216.1 KiB157133

ar.cH A D14-Feb-20219.2 KiB348193

begin.cH A D14-Feb-20218.9 KiB386223

checksum.cH A D14-Feb-20214.5 KiB16467

clscook.cH A D14-Feb-202110.1 KiB431306

cntl.cH A D14-Feb-20211.8 KiB7943

cook.cH A D14-Feb-20216.5 KiB239115

data.cH A D14-Feb-20212.6 KiB7315

decl.hH A D14-Feb-202112.6 KiB417243

end.cH A D10-Dec-20213.2 KiB14794

error.cH A D14-Feb-20213.3 KiB14387

fill.cH A D14-Feb-20211.2 KiB4512

flag.cH A D14-Feb-20213.4 KiB184135

gelf.cH A D14-Feb-202123.3 KiB1,126832

getarhdr.cH A D14-Feb-20211.5 KiB6328

getarsym.cH A D14-Feb-20216.8 KiB258132

getbase.cH A D14-Feb-20211.7 KiB7030

getdata.cH A D14-Feb-20217.9 KiB317191

getehdr.cH A D14-Feb-20211.5 KiB7132

getident.cH A D14-Feb-20211.6 KiB7032

getphdr.cH A D14-Feb-20211.5 KiB6832

getphnum.cH A D14-Feb-20212 KiB7830

getscn.cH A D14-Feb-20212.1 KiB10058

getshdr.cH A D14-Feb-20211.5 KiB6832

getshnum.cH A D14-Feb-20212.3 KiB8032

getshstrndx.cH A D14-Feb-20211.9 KiB7028

hash.cH A D14-Feb-20211.3 KiB4914

input.cH A D14-Feb-20217.1 KiB275132

kind.cH A D14-Feb-20211.2 KiB4714

libelf.32.msgH A D14-Feb-20213.4 KiB141133

libelf.msgH A D14-Feb-20215.2 KiB150116

mapfile-versH A D14-Feb-20213.2 KiB179166

member.hH A D14-Feb-20212.3 KiB8922

ndxscn.cH A D14-Feb-20211.2 KiB5016

newdata.cH A D14-Feb-20212.3 KiB9551

newehdr.cH A D14-Feb-20212.7 KiB11859

newphdr.cH A D14-Feb-20213.4 KiB14176

newscn.cH A D14-Feb-20212.8 KiB11875

next.cH A D14-Feb-20211.4 KiB6025

nextscn.cH A D14-Feb-20211.4 KiB5925

output.cH A D14-Feb-20212.5 KiB10144

rand.cH A D14-Feb-20211.7 KiB7739

rawdata.cH A D14-Feb-20212.9 KiB13181

rawfile.cH A D14-Feb-20211.7 KiB7741

rawput.cH A D14-Feb-20211.6 KiB7532

strptr.cH A D14-Feb-20212.7 KiB11975

update.cH A D14-Feb-202124.1 KiB1,007576

xlate.m4H A D14-Feb-202145.4 KiB2,0071,702

xlate64.m4H A D14-Feb-202147 KiB2,0991,785


4# The contents of this file are subject to the terms of the
5# Common Development and Distribution License (the "License").
6# You may not use this file except in compliance with the License.
8# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9# or
10# See the License for the specific language governing permissions
11# and limitations under the License.
13# When distributing Covered Code, include this CDDL HEADER in each
14# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15# If applicable, add the following below this CDDL HEADER, with the
16# fields enclosed by brackets "[]" replaced with your own identifying
17# information: Portions Copyright [yyyy] [name of copyright owner]
23# Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
24# Use is subject to license terms.
28Why 32-bit libelf is not Large File Aware
31The ELF format uses unsigned 32-bit integers for offsets, so the
32theoretical limit on a 32-bit ELF object is 4GB. However, libelf
33imposes a 2GB limit on the objects it can create. The Solaris
34link-editor and related tools are all based on libelf, so the
3532-bit version of the link-editor also has a 2GB limit, despite
36the theoretical limit of 4GB.
38Large file support (LFS) is a half step between the 32 and 64-bit
39worlds, in which an otherwise 32-bit limited process is allowed to
40read and write data to a file that can be larger than 2GB (the extent
41of a signed 32-bit integer, as represented by the system type off_t).
42LFS is useful if the program only needs to access a small subset of
43the file data at any given time (e.g. /usr/bin/cat). It is less useful
44if the program needs to access a large amount of data at once --- having
45been freed from the file limit, the program will simply hit the virtual
46memory limit (4GB).
48In particular, the link-editor generally requires twice as much
49memory as the size of the output object, half to hold the input
50objects, and half to hold the result. This means that a 32-bit
51link-editor process will hit the 2GB file size limit and the 4GB
52address space limit at roughly the same time. As a result, a
53large file aware 32-bit version of libelf has no significant value.
54Despite this, the question of what it would take to make libelf
55large file aware comes up from time to time.
57The first step would be to provide alternative versions of
58all public data structures that involve the off_t data type.
59These structs, found in /usr/include/libelf.h, are:
61	/*
62	 * Archive member header
63	 */
64	typedef struct {
65		char		*ar_name;
66		time_t		ar_date;
67		uid_t		ar_uid;
68		gid_t 		ar_gid;
69		mode_t		ar_mode;
70		off_t		ar_size;
71		char 		*ar_rawname;
72	} Elf_Arhdr;
75	/*
76	 * Data descriptor
77	 */
78	typedef struct {
79		Elf_Void	*d_buf;
80		Elf_Type	d_type;
81		size_t		d_size;
82		off_t		d_off;		/* offset into section */
83		size_t		d_align;	/* alignment in section */
84		unsigned	d_version;	/* elf version */
85	} Elf_Data;
87As off_t is a signed type, these alternative versions would have to use
88an off64_t type instead.
90In addition to providing alternative large file aware Elf_Arhdr and
91Elf_Data types, it would be necessary to implement large file aware
92versions of the public functions that use them, also found in
95	/*
96	 * Function declarations
97	 */
98	unsigned  elf_flagdata(Elf_Data *, Elf_Cmd, unsigned);
99	Elf_Arhdr *elf_getarhdr(Elf *);
100	off_t	  elf_getbase(Elf *);
101	Elf_Data  *elf_getdata(Elf_Scn *, Elf_Data *);
102	Elf_Data  *elf_newdata(Elf_Scn *);
103	Elf_Data  *elf_rawdata(Elf_Scn *, Elf_Data *);
104	off_t	  elf_update(Elf *, Elf_Cmd);
105	Elf_Data  *elf32_xlatetof(Elf_Data *, const Elf_Data *, unsigned);
106	Elf_Data  *elf32_xlatetom(Elf_Data *, const Elf_Data *, unsigned);
107	Elf_Data  *elf64_xlatetof(Elf_Data *, const Elf_Data *, unsigned);
108	Elf_Data  *elf64_xlatetom(Elf_Data *, const Elf_Data *, unsigned);
110It is important to note that these new versions cannot replace the
111original definitions. Those must continue to be available to support
112non-large-file-aware programs. These new types and functions would be in
113addition to the pre-existing versions.
115When you make code like this large file aware, it is necessary to undertake
116a careful analysis of the code to ensure that all the surrounding code uses
117variable types large enough to handle the increased range. Hence, this work
118is more complicated than simply supplying variants that use a bigger
119off_t and rebuilding --- that is just the first step.
121There are two standard preprocessor definitions used to control
122large file support:
127These preprocessor definitions would be used to determine whether
128a given program linked against libelf would see the regular, or
129the large file aware versions of the above types and routines.
130This is the same approach used in other large file capable software,
131such as libc.
133Finally, all the applications that rely on libelf would need to be made
134large file aware. As with libelf itself, there is more to such an effort
135than recompiling with preprocessor macros set. The code in these
136applications would need to be examined carefully. Some of these programs
137are very old, and were not originally written with such type portability
138in mind. Such code can be difficult to transition.
140To work around the 2GB limit in 32-bit libelf:
142    - The fundamental limits of a 32-bit address space mean
143      that a program this large should be 64-bit. Only a 64-bit
144      address space has enough room for that much code, plus the
145      stack and heap needed to do useful work with it.
147    - The 64-bit version of libelf is also able to process
148      32-bit objects, and does not have a 2GB file size limit.
149      Therefore, the 64-bit link-editor can be used to build a 32-bit
150      executable which is >2GB. The resulting program will consume over
151      half the available address space just to start running. However,
152      there may be enough address space left for it to do useful work.
154      Note that the 32-bit limit for sharable objects remains at
155      2GB --- imposed by the runtime linker, which is also not large
156      file aware.