bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: gas/ia64 "data in a code section" problem


From: Jim Wilson
Subject: RE: gas/ia64 "data in a code section" problem
Date: 29 Jun 2004 19:38:55 -0700

On Tue, 2004-06-29 at 18:40, Belochapka, Konstantin wrote:
> First reason - Itanium allows memory read and even write from/to executable 
> memory fragment, so if the hardware supports this then is no reason to 
> disable this in an assembler.

What the hardware allows, and what the assembler allows are different
things.  Just because you can read/write to executable memory doesn't
mean that the assembler must allow data in the text section.  You can
define your own sections that contain data and make them executable. 
You can insert nops into the data stream, and overwrite them with data. 
Etc.

If you are coming from an x86 background, then you may be expecting
things to work that can not work on IA-64.  On x86, the assembler is
straight forward.  It just translates the input assembly code to the
output object file without much processing.  In this kind of situation,
you can get away with mixing code and data.  However, in the IA-64
world, the assembler is pretty complicated.  It does a lot of automatic
processing of the input assembly code, including generating info that
was not explicitly in the input.  This includes things like bundling,
emitting stop bits, dependency violation checking, and generating unwind
info.  The only way we can accurately perform all of these tasks is if
we require that the input be well structured.  And well structured input
means no data in the text section.  If we violate this rule, then some
parts of the assembler may not work correctly, and you are likely to run
into trouble.

It is in your own interest to avoid putting data in the text section. 
And if you really do need to put it there, then you should take pains to
ensure that you won't confuse the assembler, e.g. emit data that is
16-byte aligned and a multiple of 16-bytes in size, emit branches around
the data, emit data outside function boundaries, etc.

Note also the .xdata directives which make it easy to emit data into a
different section than the current one.  These are useful for emitting
data while in the text section, since you can direct the data to be
emitted in some other section, such as rodata, without needing to change
the current section.

> Second - a compiler can put constant data into .text section, the things like 
> constant strings and switch/case tables.

There is no need for a compiler to put constant data in the text
section.  In both ELF and COFF (Windows), you can put constant data in
the rodata section.  If you are using an old and broken object file
format like a.out, then you would have a problem, but there are no IA-64
targets that I know of that use old broken object file formats.  Maybe
you are trying to do ia64-vms work?  I don't know what object file
format vms uses.

The IA-64 ABI incidentally does not allow putting switch tables in the
text section.

Strings should likewise go into a rodata section, or better yet, into a
special string section.  GNU ld has support for merging string sections,
and eliminating duplicate strings.

> Third - Intel Assembler Manual does not mentioned any restriction for this 
> and IAS handles this situation without any problem. 

IAS is known to allow some kinds of unstructured input that can not work
in GNU as.  I haven't looked closely at IAS, so I don't know if it is
just emitting bad output without giving warnings, or if it is actually
complicated enough to get these cases right.  But in the case of GNU as,
it is unlikely that we will ever get some of these cases right.  It is
just too hard to make unstructured input work, and you should avoid it
if you want to use GNU as.

To get the best results from the IA-64 GNU as port:
1) Never emit data into the text section.
2) Never change sections while in the middle of a function.
You can avoid both of these by using the .xdata directive.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]