mirror of
https://github.com/darlinghq/darling-gdb.git
synced 2024-12-02 17:16:42 +00:00
573da2f371
(for the sake of makes that don't realize they're the same). * PORTING: Add more details. * genscripts.sh: Add more tailorability of DATA_ALIGNMENT.
153 lines
5.2 KiB
Plaintext
153 lines
5.2 KiB
Plaintext
Preliminary Notes on Porting GNU ld
|
|
-----------------------------------
|
|
|
|
Before porting ld itself, you will need to port the BFD library;
|
|
see ../bfd/PORTING.
|
|
|
|
The 'host' is the system a tool runs *on*.
|
|
The 'target' is the system a tool runs *for*, i.e.
|
|
a tool can read/write the binaries of the target.
|
|
Most often, host==target, but ld supports cross-linking
|
|
(and to some extent the same ld binary can be used a linker
|
|
for multiple target rachitectures).
|
|
|
|
Porting to a new host
|
|
---------------------
|
|
Pick a name for your host. Call that <host>.
|
|
You need to create the file config/mh-<host>.
|
|
|
|
Porting to a new target
|
|
-----------------------
|
|
Pick a name for your target. Call that <target>.
|
|
You need to create at least config/mt-<target>.
|
|
It should contain
|
|
EMUL=<emulation>
|
|
An <emulation> controls the "personality" of ld,
|
|
such as the default linker script. Usually, the
|
|
<emulation> will have teh same name as the <target>,
|
|
and you will need to create a new <emulation> (see below).
|
|
|
|
You will also need to edit Makefile.in and possible configure.in.
|
|
To see how to do that, search for existing examples (e.g. sun3,
|
|
sun4, hp300bsd).
|
|
|
|
Porting to a new emulation target
|
|
---------------------------------
|
|
Pick a name for your target. Call that <emulation>.
|
|
Usually, <emulation> and <target> are the same.
|
|
You need to create at least <emulation>.sh.
|
|
You will also need to edit Makefile.in,
|
|
To see how to do that, search for existing examples.
|
|
|
|
The file <emulation>.sh defines a set of parameter that
|
|
are used to generate the emulation. Its syntax is that
|
|
of a (Bourne) shell script, and it is "sourced" by genscripts.sh.
|
|
|
|
Writing <emulation.sh>
|
|
----------------------
|
|
|
|
Usually, <emulation>.sh contains:
|
|
EMULATION_NAME=<emulation>
|
|
SCRIPT_NAME=<script>
|
|
OUTPUT_FORMAT="<target-name>"
|
|
TEXT_START_ADDR=<text_start_addr>
|
|
PAGE_SIZE=<page_size>
|
|
SEGMENT_SIZE=<segment_size> # If different from PAGE_SIZE.
|
|
ARCH=<arch>
|
|
|
|
<target-name>
|
|
Matches the 'filename' field of the bfd_target you want
|
|
to use. (This is a string, and currently the first field.)
|
|
For an a.out target, <target-name> matches the TARGETNAME
|
|
defined in ../bfd/<target>.c.
|
|
|
|
<arch>
|
|
The architecture: e.g. m68k, sparc, ...
|
|
|
|
<script>
|
|
The file <script>.sc-sh is a shell script which when
|
|
eveluated (by genscripts.sh) writes a linker script
|
|
file to standard output. You may need to write a new
|
|
script. If you use the a.out format or something
|
|
similar, you can probably set
|
|
SCRIPT_NAME=aout
|
|
|
|
<text_start_addr>
|
|
<page_size>
|
|
<segment_size>
|
|
These set the shell variables TEXT_START_ADDR, PAGE_SIZE,
|
|
and SEGEMNT_SIZE for use by <script>.sc-sh.
|
|
If your script doesn't use these variables, you
|
|
don't have to define the variables,
|
|
For emulations using a.out files, you can get these
|
|
values from ../bfd/<target>c.
|
|
|
|
In some cases, you may need more more definitions.
|
|
For example, if you can't use generic.em,
|
|
you may need to add:
|
|
TEMPLATE_NAME=<emulation>
|
|
and write your own <emulation>.em file.
|
|
|
|
Writing a new <script>.sc-sh
|
|
----------------------------
|
|
|
|
You may need to write a new script file for your emulation.
|
|
|
|
Your script can use the shell variable LD_FLAG, which has the value:
|
|
LD_FLAG= when building a script to be used by default
|
|
LD_FLAG=n when building a script to be used for ld -n
|
|
LD_FLAG=N when building a script to be used for ld -N
|
|
LD_FLAG=r when building a script to be used for ld -r
|
|
LD_FLAG=u when building a script to be used for ld -Ur
|
|
|
|
The variable RELOCATING is only set if relocation is happening
|
|
(i.e. unless the linker is invoked with -r).
|
|
Thus your script should has an action ACTION
|
|
that should only be done when relocating,
|
|
express that as:
|
|
${RELOCATING+ ACTION}
|
|
In general, this is the case for most assignments, which should look like:
|
|
${RELOCATING+ _end = .}
|
|
|
|
Also, you should assign absolute addresses to sections only
|
|
when relocating, so:
|
|
.text ${RELOCATING+ ${TEXT_START_ADDR}}:
|
|
|
|
The forms:
|
|
.section { ... } > section
|
|
should be:
|
|
.section { ... } > ${RELOCATING+ section}
|
|
|
|
RELOCATING is set except when LD_FLAG=r or LD_FLAG=u.
|
|
CONSTRUCTING is set except when LD_FLAG=u.
|
|
|
|
Alignment of the data segments is controlled by the variables
|
|
DATA_ALIGNMENT_ (note trailing underscore), DATA_ALIGNMENT_n,
|
|
DATA_ALIGNMENT_N, DATA_ALIGNMENT_r, or DTA_ALIGNMENT_u
|
|
depending on LD_FLAGS's value.
|
|
Normally, the default value works (this is "ALIGN(${SEGMENT_SIZE})"
|
|
for the _n, and __ (default) variants; "." for the _N, variant;
|
|
and "" for the _r and _u variants).
|
|
|
|
Handling -n and -N style binaries in your linker script
|
|
-------------------------------------------------------
|
|
|
|
The -n linker flag requests the linker to create a binary
|
|
with a write-protected text segment, but not demand-pagable (NMAGIC).
|
|
Sunos starts the text segment for demand-paged binaries at 0x2020
|
|
and other binaries at 0x2000, since the exec header (0x20 bytes)
|
|
is paged in with the text. Some other Unix variants do the same.
|
|
|
|
In that case, the <emulation.sh> should define:
|
|
|
|
NONPAGED_TEXT_START_ADDR
|
|
The text start address to use when linking with -n or -N flags.
|
|
|
|
For example, on a sun4:
|
|
TEXT_START_ADDR=0x2020
|
|
NONPAGED_TEXT_START_ADDR=0x2000
|
|
|
|
The -N linker flag requests the linker to create a binary
|
|
without a write-protected text segment (NMAGIC).
|
|
This is like -n, except that the data segment needs not be page-aligned.
|