Re: [musl] Static linking is broken after creation of DT_TEXTREL segment

[Rich Felker <dalias@libc.org>]

On Fri, Jan 31, 2020 at 08:51:05PM +0300, Андрей Аладьев wrote:
> > Moreover, adding such a thing is not desirable because it adds a
> linear-search of an array of load segments to each relocation
> 
> I think it is possible to make this search O(log n).

This would help if n were large, but in practice it's very small (2-3
or maybe 4) and the cost is just the code path overhead, which gets
worse if you do that, not the largeness of n.

> for (j=0; v-p->loadmap->segs[j].p_vaddr >= p->loadmap->segs[j].p_memsz;
> j++);
> 
> This code takes first segment that can handle address. It looks possible to
> create modified list of virtual segments, that won't overlap and make a
> binary search.

They're non-overlapping anyway but not necessarily sorted, and can't
be simultaneously sorted by addr and p_vaddr since the orders will
differ.

> > This is not a reasonable tradeoff and it's why I proposed the "hull"
> approach
> 
> It may not be safe from maintainability perspective. Library will be
> changed, everybody will forget what part of code was protected by external
> validation and it will provide unexpected behaviour. Please consider double
> validation approach: 

You're really not making sense here. What does "protected by external
validation" mean? There is presently nothing being "protected" here;
the discussion is just about more informative errors. If this is used
as a boundary for some sort of safety at some point in the future (as
mentioned before, the benefit of this is probably limited to ldd and
thus not very useful) then it will be done according to constraints
needed to achieve that.

> external validation in production and debug only mode
> with loadmap like validation.

We do not have separate "production" and "debug" modes. This kind of
thing (combinatoric build-time options) is what lacks maintainability.

Rich