Re: ld: separate output sections for incompatible orphans

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Alan Modra wrote:
> On Sat, May 16, 2009 at 02:00:30PM +0100, Dave Korn wrote:

>>   It did indeed, but are we sure duplicate output section names don't cause
>> any problems for any of the runtime loaders?
> 
> I'd appreciate some testing, especially for PE.  :-)  For ELF I'm
> reasonably certain that it won't cause a problem.

  Ok, when I get a spare moment I'll give it a go, it should be simple enough
to compile an executable from the testcase you added and try it out.

  I use bog-standard windows desktop OS.  The cegcc/windows mobile crew
apparently have a tougher time with the strictness of the runtime loader on
their platforms; perhaps Vincent or someone will have a chance to try it
there.  We can always provide a fallback to some other behaviour if they need it.

>>  Or will this only happen in
>> relocatable links and be resolved by the final link before execution?
> 
> No, this change affects final link.

  Right, just verifying that this will indeed be visible to the runtime loader.

>>   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?
> 
> I guess I should have asked permission before I messed with your
> test. :-)  

  Heh.  For the avoidance of all possible doubt, it is absolutely not "my"
test.  It belongs to the FSF :) and I have absolutely no intention of ever
getting possessive or precious about the stuff I contribute.  (Feel free to
remind me of my words if I ever do.)

> Yes, this was to avoid proliferation of .exp files.  More
> .exp files means slightly slower testsuite runs, for all targets.
> There isn't really any reason to put simple run_dump_test style tests
> in separate files.  You can select targets, set as and ld flags
> etc. all in their .d files.  I think the ideal is one main .exp file
> per directory to handle all the simple tests, with other .exp files as
> necessary for more complex tests, but it's not terribly important.

  Righto.  In that context, I was about to either add a new .exp file, or have
to do this:

###########################################################################
###########################################################################
##                                                                       ##
##  Tests before this point do not require a compiler, and can be run    ##
##  in a cross-binutils-only build.  Tests beyond this point require a   ##
##  target compiler and will not be tested cross without one.            ##
##                                                                       ##
###########################################################################
###########################################################################

# No compiler, no test.
if { [which $CC] == 0 } {
    untested "aligned common tests"
    # Add more "untested" directives here when adding more tests below.
    return
}

set align_tests {
  {"aligned common 1" "" "" {aligncomm-1.c}
   {{nm -C aligncomm.d}} "aligncomm-1.x"}
  {"aligned common 2" "" "" {aligncomm-2.c}
   {{nm -C aligncomm.d}} "aligncomm-2.x"}
  {"aligned common 3" "" "" {aligncomm-3.c}
   {{nm -C aligncomm.d}} "aligncomm-3.x"}
  {"aligned common 4" "" "" {aligncomm-4.c}
   {{nm -C aligncomm.d}} "aligncomm-4.x"}
}

run_ld_link_tests $align_tests

... down at the bottom of pe.exp, but maybe it would be nicer to merge this
and vers-script.exp so that we then have pe.exp = simple tests that require
only binutils and can be tested cross, <merged vers_script.exp + aligncomm
tests>.exp = more complex tests that require a cross compiler, and direct.exp
(could perhaps rename at some future time if adding more tests) that requires
not just a compiler but to be able to run the test on the native machine.

>>   We don't generally insist on one function parameter per-line elsewhere in .c
>> files in ld or bfd; 

> The formatting changes happened because I was comparing pe.em and
> pep.em, removing differences, that's all.  I wasn't trying to set
> a formatting standard.  ;-)

  Great, will happily disregard :)

    cheers,
      DaveK