This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Moving _etext to after all read-only sections


Hi Jason,

: Something else caused me to notice this, but it seems like a bug
: in any case.
: 
: In Binutils 2.9 and also in Binutils-current, _etext is placed
: after .text but before .rodata, etc.  This is fine for normal
: applications (the read-only sections are gathered together in
: a single, contiguous read-only section from the point of view
: of a program loader).  But for e.g. an operating system kernel,
: this is problematic.  The kernel, while bootstrapping VM, only
: really has the _etext symbol to work with if it wants to map
: the text and read-only data of the kernel as read-only.  The
: end result is that const data ends up being writable.

: Does anyone have any thoughts as to the wisdom of this change?

I think it would be a bad idea.  The _etext symbol is intended to mark
the end of the text sections, not the end of read-only text-and-data.

: It occurred to me as the obvious one (over e.g. adding a new
: _ereadonly symbol, or something) because of the comment near
: the beginning of the template:
: 
:   /* Read-only sections, merged into text segment: */

Ah, but -  this comment is talking about test segments not text
sections.  What it means is that the script has gathered together all
of the read-only sections into one place so that they can all be
placed into a single read-only segment.

I think that adding a new symbol _ereadonly would actually be a better
approach.

I am unsure however why an OS would need this symbol.  If it just
wants to locate the read-only parts of an application why not examine
the program header, find all the read-only and allocatable segments
(there will probably only be one) and then map them ?

: A simple patch to the 2.9 elf.sc fixes this... but it looks
: like it might be more complicated in Binutils-current (what
: is WRITABLE_RODATA anyhow?

It appears to be exactly what it sounds - a variable which if it is
defined by the emulation parameters will cause the .rodata section to
be placed into a writable segment.  It is not clear why this should
be necessary, but that is what it does.

: -- also I'm not completely clear
: on the CREATE_SHLIB-SDATA2 and CREATE_SHLIB-SBSS2 stuff).

CREATE_SHLIB is a variable that is defined if a shared library is
being created.  The elf.sc linker script uses this to control the
placement and presence of various sections and symbols.  SDATA2 and
SBSS2 refer to the .sdata2 and .sbss2 sections which are used on
certain targets.

Cheers
	Nick



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]