[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gas/ia64 "data in a code section" problem
RE: gas/ia64 "data in a code section" problem
Tue, 29 Jun 2004 22:40:59 -0700
Of course I agree that if anyone puts a data into code segment does this at his
own risk. But my point is that an assembler also should not any restriction
based on assumption of any potential problem.
The situation when IA64 assembler starts next bundle from an address that is
not aligned on 16 bytes
in my opinion is a bug that need to be corrected or it might be mentioned in a
README file that after a data .align 16 directive is a requirement. But
emitting error message would be not good solution, warning might be more
From: Jim Wilson [mailto:address@hidden
Sent: 29 June 2004 19:39
To: Belochapka, Konstantin
Subject: RE: gas/ia64 "data in a code section" problem
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.
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
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
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