lahumphreys / elf64-linker Goto Github PK

Currently the elf builder doesn't use the Header class and is therefore missing required attributes.

This will require enhancements to the ElfHeader object

Define a new object to represent the LINK library in python

-> constructed from a valid .LIBRARY file
-> Searchable symbol table
-> indexable elf files: (a map to an instance of Parsedfile)

Currently when a symbol is resolved a pointer is set in the symbol object to the map in another symbol object.

The problem is, if this map is assigned (maybe this symbol gets resolved in turn?) this is not propagated to any symbols that are pointing to it

currently it inherits only from the individual interfaces.

Make sure the inheritance is virtual to prevent compile errors!

I'm assured that some point during the last Ice age it became fashionable to define the build process in needlessly verbose XML files that no one can read (but hey - their real easy to parse and write clunky IDEs for...).

Add the ability to build the project using Maven (or some such newfangled monstrosity), the resulting build file should have all the same features as makefile.include.

Particularly:

• Support for library / binary / tests structure, with an external export director
• Ability to run compile time tests
• Ability to run Memtest, and integrate with vim

Bonus points if the result is actually maintainable, - and a human being can read it...

Currently the super class is left with an out of date mapping of the flags after the call to AddExecutable.

Currently the stringtable produced by elf2elf is corrupt.

Build a test script to validate the output
#28 is required first

Use the new binary reader interface to extend the library to handle elf libraries

Change #9 will create an interface to handle archive files

Use this to parse the library:

-> Read the master symbol table
-> Parse the libraries (this should be simple: parse each reader object to a new elfParser)
-> Provide a method to write in (single file) LINK format

This is reliant on #9

Despite efforts to the contrary, the time for the profiler to run varies massively between systems.

The run multiplier should be a compile time variable - that can be set in the environment

As readable as the LINK format is, programatically its a nightmare.

An object should be created to read in the LINK file and provide an interface to access its members, this is the first stage into making the library object initialise themselves from a LINK format.

Note: The existing library object should retain all the logic for processing their own pieces of the object files => the object is nothing more than a fancy dictionary of text strings...

void StdWriter::Fill(long offset, unsigned char c, long count ) {

Add a stream operator to the BinaryReader >> which behaves as the reverse of the operator on BinaryWriter.

Remove debugging throw statement from flags.cpp

A few todo items are dotted around liblink to convert to delegated constructors, this should be done as sson as gcc 4.7 is available on the build vm

A new object provides a mechanism to add string to a string table, returning the insertion offset.

The object has a write method which can be called to insert the raw string table into fie.

It has a method to return a section header for this string table

The raw pointers in the elf parser should be changed to shared_ptr

As a point of interest, it would be good to know what effect this has on the profile

The (python) linker library is getting way too long, and is now hard to read. Break into components

Currently the archive object has a hack in it to align all sections to the next 2 byte boundrary, based on inspection of libc.a.

Its not apparent why this should be true, as there is no alignment marker in the header....

Find some documentation to verify this is correct

This is linked to issue #8

Program segments may overlap each other. Currently the elf-builder does not fascilitate this as all data sections are wirtten sequentially leading to issues such as zero-sized segments.

The mapped memory regions should be tracked so that the correct starting offset may be identified when writing out the contets

Enhance build object to handle library objects created by #12

Currently all the individual objects in libLInk read directly from an elfReader object. This is unecessarily restrictive and is going to make handlin libraries hard

abstract away the reader object, this also proivdes an opportunity to clean up the constructors so they no longer need integer offsets within the files they are reading from

A new binary write , and position abstraction is required. A small virtual tempate for the writer object and a simple position object mirroring that for the reader object is required.

std::ofstream is probably good enough for the uderlying writer

Currently the Add / Remove functions from ProgramHeader are directly exposed.

These would corrupt the flags object and should not be exposed form this class

Create a new reader that can be initialised by a position and a reader object

(this will essentially be a thin wrapper around the underlying reader object)

required for #9

Currently raw reader objects are being passed into the individual constructors, along with sizes and offsets. This is inelegant, and will potentially make an implementation for library reading v. ugly.

Create a new position object to wrap this information, and hide the reader class.

Rewrite the constructors to take this position object as a single argument

current if the depot is cloned to a machine without exuberant ctags the project won't build.

this should be fixed

We know (at the least libc) complies to the format described in the book.

Assuming this format is valid create an object to parse an archive handle and produce output as defined in the book

This is reliant on #15

This is the first stage to fixing issue #8

Currently the LINK file is bloated: once the LINK2ELF transalator is written, the link file should be reduced back towards the standard defined by John Levine

-> Remove the concept of Program headers from the LINK File

Add a << operator to the.BinaryWriter which copies an object and increments the offset

Should be templated to use sizeof to write POD.
An explicit implementation for (const char *) will also be needed.

The Archive object should handle GNU standard (//) string table member

This is linked to issue #8

g++ is complaining about an ambiguity caused by the =(long&) and the copy constructors of BinaryReader and BinaryWriter.

It seems easiest to replace the copy constructor with a factor function and maintain a private copy constructor....

This class should be split into two:

The first class should be a thing wrapper around Elf64_Shdr and provide accessors,

The second, derived from the first should provide the initialization / data access etc.

Currently the IOInterface tests have to duplicate common functions

The end result should be the same BinaryReader and BinaryWriter objects with the same signature, just with a inheritance tree

Using the object created by issue #22 the library object should be able to initialise themselves from the ELF file

As a first stage to the LINK 2 ELF transaltor, be able to write out data object back out has the elf file that created them.

The files need not be indentical, but a binary should stil be executable, and elf2link should produce the same output for a library

We're writing the null char one past the end odd the arrays

Currently the Symbol, Relocation and Section objects configure flags every time an instance is created.

Profiling the elf2elf tests identifies this as one of the most expensive operations, as it has to hash the same set of strings every time.

Since symbols in particular may be created 10s of thousands of times in a single link, this should be fixed.

This will requires some kind of enhancement to the Flags utility

Currently, when loading from elf sections does not configure the Link flag object, this will be required to write out the LINK string header

Currently the build will fail even if an issue is know and going to be fixed on a later commit.

Some kind of config file should be added if a failure is known and will be fixed later

Current ReadString is missleading - it should be replaced with two function: ReadString and AppendString

Current the arrithmitic operators in BinaryReader are not defined to handle a reference to another BinaryPosition.

This is easy to fix since the other position holds an offset as an integer

No validation of the same / compatible underlying reader object need be attempted