I solicit your feedback regarding a few design choices I've made as
part of implementing two proposed changes related to the ld magic
number options.  These changes affect only the pdp11 emulation and
they are implemented all within an expansion of the customization
files for the pdp11 emulation except for two one-line changes in the
common code as explained below.

And, to allay any concerns about the number of emails I've sent to
this list recently, I don't have any work planned beyond this.

First, to be consistent with the behavior of ld both in Unix v6 at the
beginning of Unix on the PDP11 and in 2.11 BSD at its end, the default
format for the pdp11-aout target should be --omagic, not --nmagic.
That format does not page-align the .data section and generates magic
number 0407 which indicates to the runtime system that the .text
section should not be read-only.  I've changed the default only for
the pdp11 emulation.

Second, I would like to add option --imagic to generate output with
magic number 0411 (defined as IMAGIC in Unix v6 ld.c) that puts both
the .text and .data sections starting at address 0 for loading into
the separate instruction and data spaces of larger PDP11 models.  The
Unix v6 ld selected this format with option -i, but that option
already has another meaning in binutils ld.  In 2.11 BSD the option -z
was added as a synonym for -i, so within the pdp11 emulation I also
implemented that option as a synonym for --imagic.

The expansion of the pdp11 customization consists of adding a pdp11.em
file containing _before_parse() to adjust the default config settings
consistent with --omagic.  It also contains functions _add_options(),
_list_options() and _handle_option() to implement the additional
options including printing pdp11-specific help for all of the --*magic
options.  I also needed a new _get_script() function that compiles in
a sixth linker script where the .data section starts at address 0.
Since genscripts does not produce such a script, when compiling in the
scripts I reuse the script that aligns the data to a page boundary but
edit it to set address 0 instead.

Related to this, I observe that the code in the adjust_*_magic()
functions in bfd/aoutx.h and bfd/pdp11.c that sets the VMA for data is
not effective because the alignment directive in the linker script
overrides it.

I also added a pdp11.sc file instead of using aout.sc so I could
remove some sections that are extraneous for the pdp11 emulation.

The design choices that I want to check with you are as follows:

  - I have used the existing boolean ld_config_type::separate_code to
    indicate when --imagic is seen in the option parsing.  To me its
    meaning seemed consistent with the new way I'm using it, but I
    could add another boolean if that would be preferred.

  - Rather than define another flag bit in bfd_target::object_flags,
    I'm copying the state of the separate_code boolean into a local
    variable in bfd/pdp11.c at _final_link() time for reference later
    in adjust_sizes_and_vmas() as the sections are written.

  - Since the --imagic format intentionally causes the .text and .data
    sections to occupy the same memory addresses, I had to set
    command_line.check_section_addresses = 0.  Would that cause any
    other problems?

  - In my generated epdp11.c, the function name prefix is gldpdp11
    rather than gld_pdp11 since that is how the code was written in
    the emulation from which I borrowed code.  But I also saw the
    underscore included in a different emulation.  Is one of these
    considered correct?

The two one-line changes that I needed to make in common code are as
follows:

  - I needed to add i_magic to enum aout_magic in bfd/libaout.h.

  - In ld/lexsup.c, I needed to set config.text_read_only to TRUE in
    case 'n'.  This is the same as the default value of that boolean
    as initialized in ldmain.c so I assume my change won't affect any
    non-pdp11 emulation.  I need this change so that my change of the
    default value for pdp11 will work.  That boolean is initialized to
    FALSE or TRUE in case 'N' and case OPTION_NO_OMAGIC.

The diff is attached.

                                                        -- Steve