Re: Incremental linking output file editing support

[Ian Lance Taylor <iant at google dot com>]

Mikolaj Zalewski <mikolajz@google.com> writes:

>   - A class to handle file reading/writing. Extending File_read for
> writing would be problematic because it assumes there is only one
> reader and has on synchronization inside. For incremental linking of a
> file we may want to access different section by different threads in
> parallel. Do we want to extend File_read to have writing and two
> different locking models, or should I create a new class (or extend
> Output_file)? In the second case, maybe some common code could be
> moved to a common ancestor. 

I agree that extending File_read is wrong.  Extending Output_file would
be fine, or introducing a new class would be fine.

> As a separate question, do we want to mmap
> only the necessary fragments of memory of output file (like we do in
> File_read), or can we mmap the whole file (assuming that if we blow up
> the address space because of this then we will also blow it up during
> a full link and gold will not be useful for this binary).

I think it is fine to mmap the entire output file.  gold already does
that anyhow.  I've seen it fail because of that but not very
often--there is only output file, after all.

>   - A class representing the ELF output file with support for reading
> and writing. I could subclass the Object but it seems to be oriented
> for input objects, e.g. I would need to fake an Input_file object to
> create an Object. It contains boilerplate code for Elf_file over
> File_read support, what is helpful if we decide to extend File_read
> for writing but could be a problem otherwise. So, especially if we
> don't extend File_read, it may be cleaner to create a new class having
> a Elf_file member. If there is some code in Object of Sized_relobj
> that would be useful, I could try to move it to elfcpp.

I agree that this should not use Object.  As you know the existing
wrappers around Elf_file are pretty minimal.  The View class should be
pulled out of Object if it is useful, although that class is itself
tiny.

>   Are there some ways to reuse existing components that I've missed?

I don't think so.

Given that we map the entire output file, I'm not sure the
synchronization matters that much--it should never the case that one
thread wants to read data that another thread is writing.  So another
approach would be map the output file and wrap Object or something like
it on top of map for reading, while using Output_file for writing.

Ian