Proposed changes for pdp11 --*magic options

[Stephen Casner]

Nick,

>   First of all, please accept my apologies for taking such a long
>   time to reply to your email.

Thanks for your reply.  After there was no response for a while I went
ahead and filed an enhancement bug with the same questions and you
already added some comments there.

> >   - 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.
>
> I don't particularly like this approach, but I think that it is the
> best solution without making major changes to the BFD library.  Ideally
> the link_info structure should be passed down to adjust_sizes_and_vmas
> but this would mean changing target vectors.

I wonder now whether there would be some other operations in the BFD
menagerie that would need a new flag bit in bfd_target::object_flags
in order to implement the right behavior.  For example, an email in
another forum today made me realize that pdp11-aout-objdump -h does
not show the data at address 0 when the binary was made with my new
--imagic option, but for that instance the problem must be not
recognizing the different magic number.  (I have not investigated
yet.)

> The diff itself is fine.  I do have a few requests however:
>
>   * Please could you add documentation to ld/ld.texi describing
>     the new option, what it does, and also mentioning that it is
>     only for the PDP11.

What I was planning to do is add a new section 2.1.7 Options specific
to PDP-11 target.

>   * It would be nice if you could create a new linker test to check
>     the behaviour of the new feature.  I appreciate that there are no
>     PDP11 specific tests in the linker testsuite (or aout specific tests
>     for that matter).  But there is no reason that you cannot add a
>     new directory and put the test(s) inside it.

I'm willing to give this a shot.  You may not have noticed a related
question in my bug comment:  Would it be reasonable to introduce
changes to some of the existing tests to make them compatible with a
16-bit address space and reduce the number of failures for pdp11?
Those are addresses and section sizes for the "MEMORY" and "MEMORY
with symbols" tests that could be reduced to be less than 0x10000.
Also there are some script tests with a souce file having a .long
variable.  If that was .word instead, then it would work for pdp11 as
well.

I have not explored yet to see if there is some global notion of word
size that could be used by the test code or that should be used by nm
so it does not show 32-bit addresses for pdp11.

>   * Please could you add a line to ld/NEWS mentioning the new feature.
>
>   * If/when you do decide to submit the patch for inclusion, please
>    could you also provide ChangeLog entries describing what is happening.

For both of these, do you just want the patch to include edits to
these files?  It seems that the final form of the entries depends upon
the changes being merged into the official repository and committed to
a release.

Is there a way that I should provide the patch other than just a diff
attached to the bug?  I am familiar with forking and pull requests in
github, but I don't know if there is some git-specific method for
feeding changes back to binutils.

> One final thing - which really should have been the first item - I do not
> think that we have an FSF Copyright Assignment on file for you for
> contributions to the binutils project.  A change of this size/complexity
> cannot be considered to be "obvious", so an assignment will be needed.
> If you would like to fill out the form here and email it off, that will
> start the process rolling:

I did that already as soon as I saw your similar request in the bug
comment.  That was on 27 Mar 2020 with subject line "Stephen Lewis
Casner" as requested.  There will be additional files touched beyond
those listed in that email in order to update the documentation and
testsuite and possibly for objdump and nm as mentioned earlier.

Another new question: ld help says:

pdp11-aout-ld: supported targets: a.out-pdp11 srec symbolsrec verilog tekhex binary ihex plugin
pdp11-aout-ld: supported emulations: pdp11

I'm not sure that the list of supported targets is true nor where the
list is specified.  Trying "--oformat srec" gives error file format
not recognized, but so does "--oformat a.out-pdp11".

                                                        -- Steve