This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

Re: ld: separate output sections for incompatible orphans


Alan Modra wrote:
> My fix for PR6391

  6931?

> resulted in orphan input sections with incompatible
> flags and/or types being combined into one output section.  Prior to
> that ld created separate output sections for such input, with unique
> names formed by appending a suffix to the input section name.  This
> patch restores separate output sections for these orphan sections, but
> uses the same name.  The machinery to support duplicate output section
> names in ld turned out pleasingly simple.

  It did indeed, but are we sure duplicate output section names don't cause
any problems for any of the runtime loaders?  Or will this only happen in
relocatable links and be resolved by the final link before execution?

  But the main thing I wanted to ask was a couple of style issues:

> 	* ld-pe/longsecn.exp: Delete.
> 	* ld-pe/pe.exp: Run new test and longsecn tests.

 longsecn.exp was obviously trivial, but do you think it would be preferable
to also merge the somewhat more substantial vers-script.exp and direct.exp?
Is it important to avoid proliferation of .exp files, or was this just
low-hanging fruit?

 static bfd_boolean
-gld${EMULATION_NAME}_place_orphan (asection *s, const char *secname)
+gld${EMULATION_NAME}_place_orphan (asection *s,
+				   const char *secname,
+				   int constraint)

  We don't generally insist on one function parameter per-line elsewhere in .c
files in ld or bfd; should this be taken as a convention specifically for .em
files?

    cheers,
      DaveK


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