Re: Bug in >64k-section ELF handling when linking (with -r)

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Mon, 04 Nov 2002 09:57:30 -0500
> From: Andrew Cagney <ac131313@redhat.com>

  (I, H-P, blurted:)
> > Thanks.  But mind you, it *does* add 30m-1h(!) YMMV to running
> > the test-suite, making it quite awkward.  Until Someone
> > optimizes the code called from lang_place_orphans(), that is.
> > Another, (smaller IIRC) bottleneck is
> > lang_check_section_addresses, which can be made O(n) rather than
> > O(n*n) (n sections) by creating and comparing each section with
> > a memory map rather than all the other sections, given searching
> > the sections in increasing order and a mostly-contiguous memory
> > map.
> 
> [Mild sarcasm] Should the test be committed regardless?

It will, just not exercised for non-participating targets.
I think your sarcasm is misdirected:

>  BIG executables 
> are increasingly the norm (no matter how silly we thing they are) so a 
> little performance ``incentivisation'' might help.

Still, the case at hand (the linker or other part *generating*
>64k sections in a single file) is *not* the norm, no matter how
many sections are in the input or the size.  As noted, most of
use is that (perhaps lots of) input sections are combined to a
*few* output sections, and neither the bug just solved or the
performance problem with orphaned sections (not mentioned in the
linker script) or lang_check_section_addresses would be visible.

> More seriously, is there any chance that someone will find the time to 
> improve BFD's performance?

This is a linker problem, nothing in BFD eats time for these
cases.  Watch ldlang.c:lang_place_orphans() and the ELF linker
emulation code called from it walk up and down lists.

>  Apparently, for GDB, having the object file 
> reader use MMAP is a big win.

Again, this seems to be a problem with processing of data, not a
(disk) access problem (I can't really rule out cache problem
without looking further).  Not that there may be MMAP wins for
other cases of course, it's just that this is barking up the
wrong tree.

brgds, H-P