Discussion:
Executable memory: some apps that work on RH9 don't on FC1
Gerard Milmeister
2003-11-17 12:54:55 UTC
Permalink
Hi,

Some software, among them clisp, scm and mit-scheme don't work anymore
with FC1. One problem seems to be that on FC1 stack and malloced memory
is no longer executable, at least not without using mprotect.
Interpreters and compilers like the above commonly allocate a piece of
memory and fill it with executable code. I am sure they can be adapted
to work on FC1, but I would have preferred that the FC1 kernel would
behave in the same way as the RH9 one. Is there any way to disable this
behaviour. Trying to get the problem fixed by the upstream developers
will probably take a long time, and it seems that other Linux distros
don't show this problem...

Regards,
Gérard
--
Gérard Milmeister
Tannenrauchstrasse 35
8038 Zürich
***@bluewin.ch
Jakub Jelinek
2003-11-17 13:03:59 UTC
Permalink
Post by Gerard Milmeister
Some software, among them clisp, scm and mit-scheme don't work anymore
with FC1. One problem seems to be that on FC1 stack and malloced memory
is no longer executable, at least not without using mprotect.
Interpreters and compilers like the above commonly allocate a piece of
memory and fill it with executable code. I am sure they can be adapted
to work on FC1, but I would have preferred that the FC1 kernel would
behave in the same way as the RH9 one. Is there any way to disable this
behaviour. Trying to get the problem fixed by the upstream developers
will probably take a long time, and it seems that other Linux distros
don't show this problem...
If they need executable stack in a way which is not known to the compiler,
the programmer has to tell it to the toolchain.
If a program say takes address of a nested function, GCC knows it needs
executable stack and arranges things automatically.
Otherwise, either an object file can be marked as needing executable
stack (with -Wa,--execstack; at least one such object will make the whole
shared library or binary requiring executable stack), or during link
time with -Wl,-z,execstack or after it using execstack(8) utility.
The defaults are such that programs and/or libraries compiled/linked
on <= RHL9 are always assumed to potentially require executable stack,
but if you build a new program on FC1, you really need to tell the toolchain
about it.

Jakub
g***@bluewin.ch
2003-11-17 13:39:00 UTC
Permalink
Post by Jakub Jelinek
If they need executable stack in a way which is not known to the compiler,
the programmer has to tell it to the toolchain.
If a program say takes address of a nested function, GCC knows it needs
executable stack and arranges things automatically.
Otherwise, either an object file can be marked as needing executable
stack (with -Wa,--execstack; at least one such object will make the whole
shared library or binary requiring executable stack), or during link
time with -Wl,-z,execstack or after it using execstack(8) utility.
The defaults are such that programs and/or libraries compiled/linked
on <= RHL9 are always assumed to potentially require executable stack,
but if you build a new program on FC1, you really need to tell the toolchain
about it.
Jakub
Thanks for the info. However this seems to be not the only problem.
I tried the execstack method on the mentioned programs without
any success.
Or try to approach it in another way:
The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme)
segfaults if called with 'scheme -compiler'. In this case the scheme main
program load a 'band' called compiler.com, which contains executable code.
Could somebody investigate this issue? I am not that familiar with problems
like this.
Tim Daly
2003-11-17 14:21:59 UTC
Permalink
I'll look at the clisp memory issue. We plan to support Axiom on
clisp in the future so it's in our interest.

Tim Daly
***@tenkan.org
***@idsi.net
Roland McGrath
2003-11-17 19:12:02 UTC
Permalink
Post by g***@bluewin.ch
The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme)
segfaults if called with 'scheme -compiler'. In this case the scheme main
program load a 'band' called compiler.com, which contains executable code.
Could somebody investigate this issue? I am not that familiar with problems
like this.
If this binary was created with old tools and has no PT_GNU_STACK marker,
then it should get executable stack by default. More likely the issue is
that it calls malloc and expects the memory returned to be executable.
The Scheme runtime needs to be changed to use mmap when executability matters.
Tim Daly
2003-11-17 18:47:04 UTC
Permalink
Roland,

I just built a machine with the latest Fedora and tried to build Axiom.
Axiom depends on GCL, Gnu Common Lisp. It appears that all of the
lisps are broken under the new memory model.

Can you give me some pointers to any documentation or source code in
Fedora that might give me a clue about how to fix this? I understand
there might be a compiler switch but haven't found any documentation.

Tim Daly
***@tenkan.org
***@idsi.net

====================================================================
Post by g***@bluewin.ch
The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme)
segfaults if called with 'scheme -compiler'. In this case the scheme main
program load a 'band' called compiler.com, which contains executable code.
Could somebody investigate this issue? I am not that familiar with problems
like this.
If this binary was created with old tools and has no PT_GNU_STACK marker,
then it should get executable stack by default. More likely the issue is
that it calls malloc and expects the memory returned to be executable.
The Scheme runtime needs to be changed to use mmap when executability matters.
Gerard Milmeister
2003-11-17 20:28:42 UTC
Permalink
Post by Roland McGrath
Post by g***@bluewin.ch
The official binary of mit-scheme 7.7.1 (http://www.gnu.org/software/mit-scheme)
segfaults if called with 'scheme -compiler'. In this case the scheme main
program load a 'band' called compiler.com, which contains executable code.
Could somebody investigate this issue? I am not that familiar with problems
like this.
If this binary was created with old tools and has no PT_GNU_STACK marker,
then it should get executable stack by default. More likely the issue is
that it calls malloc and expects the memory returned to be executable.
The Scheme runtime needs to be changed to use mmap when executability matters.
I further investigated problem using scheme-7.7.90 and found the
following. When loading a band (the runtime image), the following is
called:

static void *
mmap_heap_malloc_1 (unsigned long requested_length, int fixedp)
{
unsigned long ps = (UX_getpagesize ());
void * addr
= (mmap (((void *) MMAP_BASE_ADDRESS),
(((requested_length + (ps - 1)) / ps) * ps),
(PROT_EXEC | PROT_READ | PROT_WRITE),
(MAP_PRIVATE | MAP_ANONYMOUS | (fixedp ? MAP_FIXED : 0)),
/* Ignored by GNU/Linux, required by FreeBSD and Solaris. */
(-1),
0));
return ((addr == MAP_FAILED) ? 0 : addr);
}

Now for the default runtime (runtime.com), requested_length == 5726028,
and the function proceeds without fault. However when the "-compiler"
switch is used to load the compiler, the all.com runtime is loaded and
then requested_length == 18563072 (this image is much bigger) and the
mmap call results in a segfault. ps is 4096, fixedp is 1 and
MMAP_BASE_ADDRESS == 4096.
Why does mmap segfault at all? Shouldn't it at worst return an error?

Hope this helps...
--
Gérard Milmeister
Tannenrauchstrasse 35
8038 Zürich
***@bluewin.ch
Roland McGrath
2003-11-17 20:50:11 UTC
Permalink
Post by Gerard Milmeister
static void *
mmap_heap_malloc_1 (unsigned long requested_length, int fixedp)
{
unsigned long ps = (UX_getpagesize ());
void * addr
= (mmap (((void *) MMAP_BASE_ADDRESS),
(((requested_length + (ps - 1)) / ps) * ps),
(PROT_EXEC | PROT_READ | PROT_WRITE),
(MAP_PRIVATE | MAP_ANONYMOUS | (fixedp ? MAP_FIXED : 0)),
/* Ignored by GNU/Linux, required by FreeBSD and Solaris. */
(-1),
0));
return ((addr == MAP_FAILED) ? 0 : addr);
}
Now for the default runtime (runtime.com), requested_length == 5726028,
and the function proceeds without fault. However when the "-compiler"
switch is used to load the compiler, the all.com runtime is loaded and
then requested_length == 18563072 (this image is much bigger) and the
mmap call results in a segfault. ps is 4096, fixedp is 1 and
MMAP_BASE_ADDRESS == 4096.
Why does mmap segfault at all? Shouldn't it at worst return an error?
When MAP_FIXED is passed (fixedp!=0), the mapping will overwrite any other
mappings that exist. So if the address range overlaps some shared
libraries or something like that, it will clobber that part of the address
space and who knows what could happen. In older kernels, shared libraries
would always end up in a high part of the address space, so assuming a huge
low region was available worked. Now shared libraries (and any mmap
region) are more likely to be located at random addresses that may be in
the low part of the address space. It has never been safe or kosher to
assume some large part of the address space would never be used for shared
libraries. cscheme needs to change its plan for calling mmap. If you need
a big contiguous region of address space into which you will place multiple
separate mappings, then the only safe thing to do is to mmap a region of
the whole needed size without MAP_FIXED (e.g. using PROT_NONE), and then
overwrite portions of that mapping with MAP_FIXED mappings to get the
layout you want.


Thanks,
Roland
Michael Schwendt
2003-11-17 20:03:00 UTC
Permalink
Post by Jakub Jelinek
Post by Gerard Milmeister
Some software, among them clisp, scm and mit-scheme don't work anymore
with FC1. One problem seems to be that on FC1 stack and malloced memory
is no longer executable, at least not without using mprotect.
Interpreters and compilers like the above commonly allocate a piece of
memory and fill it with executable code. I am sure they can be adapted
to work on FC1, but I would have preferred that the FC1 kernel would
behave in the same way as the RH9 one. Is there any way to disable this
behaviour. Trying to get the problem fixed by the upstream developers
will probably take a long time, and it seems that other Linux distros
don't show this problem...
If they need executable stack in a way which is not known to the compiler,
the programmer has to tell it to the toolchain.
If a program say takes address of a nested function, GCC knows it needs
executable stack and arranges things automatically.
Otherwise, either an object file can be marked as needing executable
stack (with -Wa,--execstack; at least one such object will make the whole
shared library or binary requiring executable stack), or during link
time with -Wl,-z,execstack or after it using execstack(8) utility.
Unfortunately:

# execstack -c $(which scheme)
execstack: /usr/bin/scheme: Reshuffling of objects to make room for
program header entry only supported for shared libraries
Post by Jakub Jelinek
The defaults are such that programs and/or libraries compiled/linked
on <= RHL9 are always assumed to potentially require executable stack,
but if you build a new program on FC1, you really need to tell the toolchain
about it.
The problem is, these are binaries built on RHL9, but run on FC1. I
haven't had the time to look at debug output yet, an strace fragment
can be found here: https://bugzilla.fedora.us/show_bug.cgi?id=823

--
Jack Aboutboul
2003-11-17 21:04:06 UTC
Permalink
Try doing this to disable exec-shield, which was a wise incorporation
into the fedora kernel, imho.

Do "echo 0 > /proc/sys/kernel/exec-shield"

This was put in specifically to make stacks not executable.

Hope it helps,
Jack
Michael Schwendt
2003-11-17 23:31:50 UTC
Permalink
Post by Jack Aboutboul
Try doing this to disable exec-shield, which was a wise incorporation
into the fedora kernel, imho.
Do "echo 0 > /proc/sys/kernel/exec-shield"
This was put in specifically to make stacks not executable.
Hope it helps,
As pointed out in the corresponding fedora.us package request bug,
disabling exec-shield is not enough.

--
Roland McGrath
2003-11-17 19:34:15 UTC
Permalink
You can disable the exec-shield functionality globally with
/proc/sys/kernel/exec-shield, but that doesn't do anything different for an
older binary that is not marked or for a binary that is marked as requiring
executable stack. exec-shield is always disabled for those execs.

The issue you are having is probably that malloc does not use PROT_EXEC in
its mmap-based allocations. Executability should be enabled in the brk
area when exec-shield is disabled. Verify the situation by looking at
/proc/PID/maps for the process in question.
Roland McGrath
2003-11-17 20:32:22 UTC
Permalink
Post by Tim Daly
I just built a machine with the latest Fedora and tried to build Axiom.
Axiom depends on GCL, Gnu Common Lisp. It appears that all of the
lisps are broken under the new memory model.
Can you give me some pointers to any documentation or source code in
Fedora that might give me a clue about how to fix this? I understand
there might be a compiler switch but haven't found any documentation.
Unfortunately I don't think we've succeeded in getting proper documentation
up to date in step with the implementation of the features. I have written
this explanation up a couple of times, but AFAIK there is no good place to
look for it. Documentation volunteers take note! :-)

The important changes have to do with what memory will be executable
(i.e. have the PROT_EXEC bit set on those pages). If you have an issue
with memory layout that changed, other than the question of executability,
then you almost surely have a bug in your application or have uncovered one
in the system. I'd be glad to help you understand which of those it is and
how to fix it. There is at least one known issue of this nature (brk
address). Please try to determine if nonexecutability alone is what's
breaking you, and if not, please post the details of your problem so we can
determine what different problem there might be.

The status quo ante was that the stack was executable, and the brk area
(used by malloc for small allocations) was executable, and on x86 pages
with PROT_READ set but PROT_EXEC did not have any enforcement of
nonexecutability anyway. All of these things are either just as they were
before, or different now, on a per-process granularity (changed by exec calls).

System-wide, you can disable the exec-shield functionality with:

echo 0 > /proc/sys/kernel/exec-shield

If that doesn't make your binaries work, then you probably have a different
problem. If it does, then the system-wide switch is a stop-gap you can use
while getting your binaries fixed. We have also overloaded the inherited
"personality" setting so you can disable it per-process:

setarch i386 foobar

That runs "foobar" with the "personality" bits set such that exec-shield is
disabled for that process and its children (unless one of them uses setarch
or is setuid or somesuch). Again, if that doesn't make your binaries work,
then you probably have a different problem.

If disabling exec-shield momentarily does work around your problem, then
you want to figure out why you had to do that. The most common situation
is that you were using executable stack in some way that you don't really
need to, e.g. GCC nested function trampolines. You can avoid that by
rewriting the code not to use trampolines (i.e. take the address of a
nested function that uses its parent's local variables). Things like Lisp
systems that produce executable code at run time should generally avoid
using stack space for that. You also should not be using malloc or direct
brk/sbrk calls to get memory that you need to be executable--you have never
had a specified guarantee that malloc returns executable memory. For
dynamic allocation of memory where you need to put executable code, use
mmap with PROT_READ|PROT_WRITE|PROT_EXEC. It is also fine to mmap with
different protections and then use mprotect with e.g. PROT_READ|PROT_EXEC
later. It is not proper to call mprotect on memory returned by malloc,
because when you free that memory later it may be reused in ways that don't
require the executability. The same goes for the brk area. (It's also the
case that no specification guarantees that mprotect is meaningful on
malloc-returned space, though in fact it will also work as you expect on
malloc and brk/sbrk space in Linux and probably all Unixoid systems.)

If you have a genuine need for executable stack, you can put a marker in
your binary to tell the system that's what you want. This marker goes in
ELF executables (and DSOs) as the PT_GNU_STACK phdr entry, with p_flags
containing PF_X to indicate need for executable stack and not containing
PF_X to indicate no need for executable stack. I'll describe how to
compile those markers in a little later. When a binary does not have any
PT_GNU_STACK marker at all, as is the case with binaries produced by all
older tool versions, it's treated as needing executable stack to be safe.
That should retain compatibility with older systems.

The story is the same for DSOs as for executable files. The difference is
that while the kernel looks for the marker in executable files at exec
time, the dynamic linker looks at the marker in DSOs when it's loading
them. This is because an executable file that itself does not require an
executable stack might load a DSO at runtime (either as a needed library or
by using dlopen, e.g. for plug-in libraries) that does require executable
stack. In this instance, the dynamic linker stops and makes all the stacks
executable before completing the load of the DSO in question. Note that
this support applies only to the stack--if a DSO dynamically allocates
memory it needs to be executable and does that the wrong way, no marker
will work around it, the code just has to be fixed.

If you have an old DSO binary that it's not feasible for you to rebuild for
some reason (e.g. 3rd-party plug-ins for your applications), you can try
marking it using the `execstack' utility (part of the `prelink' rpm).
execstack edits an existing ELF binary for you, either to add a
PT_GNU_STACK phdr if it's missing or to set or clear the PF_X flag.
`execstack -q FILE' will tell you the current status of that file: X for
executable, - for not, and ? for an old binary with no marker at all. (You
can also use readelf -l or objdump -p to see the phdrs.) Note that there
should never really be a need to add a marker to an old executable file
because of the compatibility default--a good thing, since execstack cannot
move things around to make room for the phdr in an executable as it can in
a DSO. Remember, the default when there is no marking is to assume
executable stack is required for compatibility with older systems. Ergo,
you don't need to add a marker if it would have PF_X set. The reason to
add a marker is to avoid enabling executable stack at runtime when it's not
really needed.

When compiling from source with current tools (including those in FC1), you
don't usually need to do anything special to get the right markers into
your binaries. The way it works is that the linker produces the
PT_GNU_STACK marker when there are special marker sections in the input
object files, called ".note.GNU-stack". The flags of these sections
determine the flags of the PT_GNU_STACK entry. Your object files (.o) will
normally have these sections because GCC emits them in its assembler
output. When GCC compiles nested function trampoline code, it emits a
.note.GNU-stack section with the SHF_EXECINSTR flag set:

.section .note.GNU-stack, "x", @progbits
.previous

When GCC compiles a module that does not contain any code requiring
executable stack, it emits the complementary marker section with no
SHF_EXECINSTR flag bit:

.section .note.GNU-stack, "", @progbits
.previous

If you have assembly code of your own, then you need to add these markers.
The best way is to amend the source code with one of the assembly
directives above. If that is problematic for some reason, another thing
you can do is tell the assembler directly what to emit on the command line
using -Wa,--execstack or -Wa,--noexecstack. Finally, if you want to punt
altogether on marking your .o files properly, you can tell the linker to
ignore the marker sections and override its output setting directly on the
command using -Wl,-z,execstack or -Wl,-z,noexecstack.


Thanks,
Roland
Roland McGrath
2003-11-18 03:35:20 UTC
Permalink
I appear to be missing some of the context of this discussion. What
kernels have this behavior? I have run MIT/GNU Scheme on Debian
unstable using many different 2.4 and a handful of 2.6-test kernels,
and I haven't seen this problem.
This is about Fedora Core 1 kernels (http://fedora.redhat.com), which have
some changes to how mapping addresses are chosen.
That mapping code dates back to the days of libc5. At that time, if
you tried to map some space that overlapped a shared library, you got
an error.
I can't speak to that vintage of Linux libc or Linux kernels. The
specification of mmap has always been that MAP_FIXED overwrites other mmap
mappings, and in no recent time have shared libraries been anything other
than mmap mappings.
But the problem remains that this code doesn't do what it's supposed
to. Is there some way for me to probe the address space to find the
largest hole in a given region of the space? (Not using signal
handlers to catch SIGSEGV traps!)
If you want a Linux-specific kludge, you can always see the complete memory
map by looking at /proc/self/maps. If you want a portable programmatic
solution correct for POSIX systems with mmap, the only kind of probing you
can do is try large mmaps without MAP_FIXED and see where they fit.
[...] we need the largest possible block of space under 2^26 -- ideally
all of it.
I see.
It's possible to modify the implementation to handle a block outside
of this space
I don't think you should have to. Your address space is yours to control.
You just haven't been exercising control in the specified proper ways.
Faced with this situation, I'll probably just statically link the
program.
Support for static linking is severely limited in a variety of ways.
If you make any but the most low-level use of system library facilities,
static linking is almost certainly a recipe for future aggravation.
IMO it's a bug that the application doesn't have any control over its
address space.
The application has complete control over its address space within the size
limits provided by the kernel (3GB with most Linux kernels, 4GB-16MB with
some FC1 kernels). Presumption of what addresses the kernel will use in
cases where the specification says it may choose any address, is not an
aspect of the control interface.
I should be able to tell the linker and loader that certain areas are
reserved. That's possible with the linker, but I'm not aware of any way
to control the loader.
I'm not sure what level of control you have in mind when you distinguish
what you can specify to the linker and to the loader, or whether by "the
loader" you mean the kernel's loading of executable files, or the dynamic
linker's loading of DSOs, or both. I don't see why it's not sufficient to
specify the layout you want at link time. That you can do. If your
executable contains PT_LOAD program header entries for each region you want
reserved, it will be. You can use entries with none of PF_[RWX] set to get
PROT_NONE mappings that you can overwrite later with MAP_FIXED mappings.
So why does the kernel care where shared libraries are mapped? Why is
the application working for the kernel instead of the other way around?
You are misrepresenting reality. The kernel does not care. You specified
that you did not care, and so the kernel is doing what it thinks might be
best for you given the constraints you have specified.
Roland McGrath
2003-11-18 04:47:35 UTC
Permalink
OK, so this is the piece that I'm missing. Where can I learn more
about these header entries? I don't see anything in the libc
reference about this, even though PT_LOAD is defined by libc.
libc provides elf.h, yes. The details are part of the ELF spec, available
online from e.g. http://www.sco.com/developers/gabi/. Looking at the phdr
entries in programs with readelf -l or objdump -p, their meaning is
probably obvious. What you are probably interested in is how to control
their generation by the linker. You will need to provide your own variant
of the normal built-in link script used to link an executable, that uses
the PHDRS directive explicitly lay out sections. Here is the usual script
from `ld --verbose' for i386-*-linux-gnu hacked to add a leading load
segment at 0 for the ".reserved" section. You'll have to give the linker
an input section of that name, e.g. with:

.section ".reserved","a",@nobits
.space 0x4000000
.previous

to set the size of the output segment.


OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/local/i686-pc-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0; */

PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
reserved PT_LOAD FLAGS(0) ;
text PT_LOAD FILEHDR PHDRS ;
data PT_LOAD ;
dynamic PT_DYNAMIC ;
}

SECTIONS
{
.reserved 0 : { *(.reserved) } :reserved

/* Read-only sections, merged into text segment: */
. = 0x08048000 + SIZEOF_HEADERS;
.interp : { *(.interp) } :text :interp
.hash : { *(.hash) } :text
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn :
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1)); . = DATA_SEGMENT_ALIGN (0x1000, 0x1000);
/* Ensure the __preinit_array_start label is properly aligned. We
could instead move the label definition inside the section, but
the linker would then create the section even if it turns out to
be empty, which isn't pretty. */
. = ALIGN(32 / 8);
PROVIDE (__preinit_array_start = .);
.preinit_array : { *(.preinit_array) }
PROVIDE (__preinit_array_end = .);
PROVIDE (__init_array_start = .);
.init_array : { *(.init_array) }
PROVIDE (__init_array_end = .);
PROVIDE (__fini_array_start = .);
.fini_array : { *(.fini_array) }
PROVIDE (__fini_array_end = .);
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
} :data
.data1 : { *(.data1) }
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.eh_frame : { KEEP (*(.eh_frame)) }
.gcc_except_table : { *(.gcc_except_table) }
.dynamic : { *(.dynamic) } :data :dynamic
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin*.o(.ctors))
/* We don't want to include the .ctor section from
from the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
} :data
.dtors :
{
KEEP (*crtbegin*.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.got : { *(.got.plt) *(.got) }
_edata = .;
PROVIDE (edata = .);
__bss_start = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections. */
. = ALIGN(32 / 8);
}
. = ALIGN(32 / 8);
_end = .;
PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/DISCARD/ : { *(.note.GNU-stack) }
}
Tim Daly
2003-11-18 03:29:41 UTC
Permalink
If I do:

echo 0 >/proc/sys/kernel/exec-shield

the GCL build succeeds.
If I do:

echo 1 >/proc/sys/kernel/exec-shield

the GCL build fails.

Tim Daly
***@tenkan.org
***@idsi.net

Loading...