Re: [Nasm-devel] NASM 2.15

[Cyrill G. <gor...@gm...>]

On Mon, Jan 14, 2019 at 11:46:05AM -0800, H. Peter Anvin wrote:
> Hi,
> 
> I recently started looking at supporting > 64K sections in the ELF
> backend. This is useful because subsections can be used in ELF for a
> large number of things. The way > 64K sections is handled in ELF is that
> the symbol table is augmented with an auxiliary section which contains
> the extended section indicies.
> 
> In the process, though, I just ran into a number of things that just
> plain hurts; for one thing, we still do linear searches *everywhere* for
> the segment:section matching, we have all these special sections which
> we have ad hoc code to generate instead of using common code with the
> ordinary sections to generate them, and there are a bunch of stuff where
> we test is_elf*() for things that we could simply parameterize.
> 
> This is not a criticism of Cyrill's ELF merge work; in fact, without
> that work it would be utterly impossible to tackle this stuff at all.
> 
> There is an alternative for the ELF backend, which would be to compile
> it three times from a single source base. That way we would still have a
> single codebase, but would be able to get the speed benefits of not
> having a bunch of conditionals/parameters/etc. done at runtime, and
> perhaps the best part of it would be that we can hide away the ELF32 v.
> ELF64 differences. I personally rather like that solution, because I
> think it would allow the code to be even cleaner as it would naturally
> deal with most of the structure differences.
> 
> I did prototype a version using an RAA for index->section and a hash for
> name->section, as we currently do in the MachO backend. The speedup is
> substantial: about a factor of 3 for 30K sections and then increasing
> with the number of sections squared. This is stuff I can clean up and
> productize easily enough; I need to detangle it from the other changes I
> have been doing, though (or Chang, if you are interesting in tackling
> that that would always be appreciated.
> 
> However, all these changes make me nervous to push them into 2.14.xx. As
> such, I would like to plan to make a 2.15 release before too much
> longer, probably in Q2 2019. With Cyrill's testability changes, this has
> a lot of other benefits.
> 
> I *really* would like to see 2.15 including having at least the ELF and
> MachO backends, and ideally COFF, changed to use the modern backend
> interface. The current interface simply doesn't allow certain code
> sequences from being handled correctly, and it makes me *very* nervous
> that that is probabilistic.

Sounds like a great plan! Peter, hopefully I manage to find timeslot
on the week/weekend to fetch the new code and review it! I fear this
week gonna be heavy but still.