Problem with ld for PDP-11

[Alan Modra]

On Wed, Feb 12, 2020 at 12:29:50PM -0800, Stephen Casner wrote:
> Recently Nick Clifton applied a fix for Bug 20694 - "PDP11
> TARGET_PAGE_SIZE is incorrect" that I filed 3+ year ago.  Thanks!
> 
> In testing that fix I discoverd another bug in the PDP11 code for
> which I have a proposed fix and would like your feedback.  I also have
> some questions about the command line options that control the various
> magic numbers, but I will raise those questions separately.
> 
> The newly discovered bug is that when I add the -s option to ld to
> skip output of the symbol table, the last byte of the .data section is
> been replaced by zero if that section is of even size (a multiple of 2
> bytes long).
> 
> I found the code that does this.  Specifically for the case when no
> symbols are written, the 0 byte is written by this code in the else
> clause at line 3926 of bfd/pdp11.c:
> 
>   /* Write out the string table, unless there are no symbols.  */
>   if (abfd->symcount > 0)
>     {
>       if (bfd_seek (abfd, obj_str_filepos (abfd), SEEK_SET) != 0
> 	  || ! emit_stringtab (abfd, aout_info.strtab))
> 	goto error_return;
>     }
>   else if (obj_textsec (abfd)->reloc_count == 0
> 	   && obj_datasec (abfd)->reloc_count == 0)
>     {
>       bfd_byte b;
> 
>       b = 0;
>       if (bfd_seek (abfd,
> 		    (file_ptr) (obj_datasec (abfd)->filepos
> 				+ exec_hdr (abfd)->a_data
> 				- 1),
> 		    SEEK_SET) != 0
> 	  || bfd_bwrite (&b, (bfd_size_type) 1, abfd) != 1)
> 	goto error_return;
>     }
> 
> If the size of the .data section is odd, then the result of this code
> is to write a padding byte to make the size of the a.out file even.
> That is probably the intent of the code.

Yes.  The layout of a typical a.out file is header, text, data,
relocs, symbols, string table.  Since the code in question is handling
the case where there are no relocs, symbols or string table, ie. the
last thing in the file is data, I would guess that when the data
section size is odd that the file size does not include the padding
byte to make the data size even.  But of course if the original data
size is even you don't want to overwrite the last byte.

The correct fix then is to add a check that the original data size was
odd.  That might not be easy as you may have lost the original data
size by the time this code runs.  The AOUT code is a bit of a mess.
Oh, and if there is no data then it's the text section that might need
extending.

>  But when I tested commenting
> out this else clause the a.out file still contained a zero padding
> byte there, which suggests that it may be safe to just remove this
> else clause.
> 
> My first idea was to make the else clause conditional on whether the
> size of the .data section was odd, but from what I can see the size
> has already been rounded up by the time this code is reached and I
> could not find another variable that would hold the value before
> rounding.
> 
> It appears that the bfd/pdp11.c file was created by copying and
> modifying aoutx.h; this work was done by Lars Brinkhoff years ago.
> The corresponding else clause in aoutx.h always appends one word's
> worth of zero bytes (typically 4) to the output.  It looks like the
> intention is to pad the length of the ouput to a word boundary, but
> that would only be effective if there is some operation that truncates
> the output to the last whole word.  I don't know the code well enough
> to find that.  For the pdpd11 case, it looks like the last odd byte
> does get written with a zero pad even when the else clause is
> commented out.
> 
> I asked Lars about deleting this else clause.  He said he didn't
> remember the code well enough to say why that clause was included, but
> he agreed with my suggestion to remove it.  Do any of you readers know
> how the padding and truncation in aoutx.h is implemented so you can
> direct me to the right part of the code to compare to the pdpd11 case?
> 
> If you agree with the suggestion to delete this else clause in
> pdp11.c, how can I make that happen?  Should I file a bug and include
> the change as a patch, or push it back from git somehow (I'm not a git
> expert)?
> 
> It took a long time for bug 20694 to be addressed, and the fix was
> only committed after I happened to ask Lars about it, so I'm hoping to
> establish a more efficient and effective path for fixing this bug and
> for addressing the magic changes I'd like to propose.
> 
> Thanks for your time.
> 
> Steve Casner
> 
> p.s.  I'd be happy to provide the details of my testing if you care to
> see them.

-- 
Alan Modra
Australia Development Lab, IBM