Custom Query (93 matches)

Once upon a time when binary file loading was easy, only ELF was supported and used with the ElfLoader module.

This evolved.

Some want (and implemented) COFF support, which means we now have a CoffLoader module, and I know some asked for raw binary support. I assume there wont be long before a.out, MachO, intel hex or <insert your prefed blob here> support is asked for too.

In a C++ world, the most straightforward way to implement a loader for anything would be to have a Loader abstract class, and implement classes inheriting the loading functionnality. But as I think we will sooner or later need support for loading more than one binary file in a platform (like one for a DSP and one for a GP-CPU), this may be a problem.

So here is my proposal for an evolving API:

• Have a loader class, containing the loadable sections and indexing symbols.
• Have different pluggables loaders which are tried one after another when a file is opened.
• If a loader manages to load a file, it must add its sections and symbols to the BinaryFileLoader object.

That means a BinaryFileLoader doesn't directly parse files, but uses registered handlers for this task. This way, API is always stable, new file types can be added transparently.

This change could be done transparently, just making the internals of ElfLoader change. Unfortunately, the module name itself, "ElfLoader", will become misleading.

It would be more accurate to have a "BinaryFileLoader", with "BinaryFileSection" and "BinaryFileSymbol" inside it.

I propose the following approach

• Add-in new modules
• "typedef BinaryFileLoader ElfLoader" so that current code does not directly break, but mark it deprecated
• remove ElfLoader quickly (1 week)

In topcells and platform_desc, and DSX usage, all that needs to be changed is the following sed:

s/ElfLoader/Loader/g
s/common:elf_loader/common:loader/g

and add a Uses('common:loader'), (or any other support module needed)

Comparateur de vol et billets d'avion pas cher : ​Comparateur de vol. Tous les vols pas cher.

Me again, ... I just updated, svn works fine, thx. However, compiling topcells/caba-vgmn-multi_timer-mips32 gives the following ouput:

from /home/petrot/soclib/soclib/lib/elf_file_loader/libelfpp/src/elfpp_symbol.cc:27:

/home/petrot/soclib/soclib/lib/dpp/source/include/dpp/linked_list: In member function ‘Xconstvalue& dpp::linked_list_iterator<X, id, Xnode, Xconstvalue, forward, smart>::operator*() const [with X = elfpp::reloc, int id = 0, Xnode = dpp::linked_list_node, Xconstvalue = elfpp::reloc, bool forward = true, bool smart = false]’: /home/petrot/soclib/soclib/lib/elf_file_loader/libelfpp/src/elfpp_symbol.cc:53: instantiated from here /home/petrot/soclib/soclib/lib/dpp/source/include/dpp/linked_list:144: error: ‘dpp::linked_list_item<elfpp::reloc, 0, false>’ is an inaccessible base of ‘elfpp::reloc’ /home/petrot/soclib/soclib/lib/dpp/source/include/dpp/linked_list: In member function ‘void dpp::linked_list<X, id, smart>::push_back(X&) [with X = elfpp::reloc, int id = 0, bool smart = false]’: /home/petrot/soclib/soclib/lib/elf_file_loader/libelfpp/src/elfpp_symbol.cc:69: instantiated from here /home/petrot/soclib/soclib/lib/dpp/source/include/dpp/linked_list:340: error: ‘dpp::linked_list_item<elfpp::reloc, 0, false>’ is an inaccessible base of ‘elfpp::reloc’ soclib-cc: * Action failed with return value `256'. Stop. soclib-cc: Waiting for unfinished jobs make: * [simulation.x] Erreur 1

Any clew ? Thx