Brendon Costa wrote: > Mike Stump wrote: >> Hum, on second thought, why not just encode the information you want >> into the .o file. Just put it into a special section, in whatever >> format you like, the linker will combine them, no additional files, .a >> files work, ld -r foo.o bar.o -o new.o works and so on. You can then >> fish the information back out from the .o files or the executable as you >> want. >> > > That sounds like a great idea! I guess I need to start researching how > to embed data into .o files... Is looking at debug data generated by > the C++ front-end a good place to start? > > I assume this can be done by adding certain directives to the > assembler source file (.s), since the assembler generates the .o files. > > Anyhow, I will continue to look further into this and may get back > with more questions :-) later. Thanks for the idea. > > > Thanks, > Brendon. >
Alright after briefly looking into some info on the binutils and GNU as I have a few thoughts. I think I could insert my data into the .s file into a particular section. I am not sure if I should create my own named section used for meta-data (Only available using COFF from what I understand using the as .section directive) or maybe I could insert it into the .data section with a particular identifier. I don't understand this completely though. If I place it into the .data section then would it then be possible to have conflicts with code symbols? I am also not yet sure how I would extract this data from the objects (Using libbfd somehow I will have to look further into it). What would be the best directive to use to insert binary data into the section? I was thinking at first of using the .ascii directive as my file is just a plain text file. However in the future I would like to convert the file into a binary format and could not find a directive that would allow me to insert binary data simply. I would also need to figure out how to modify the front end to insert this data into the .s file. I have not looked into that yet so it may be as simple as inserting a node into the tree, but I don't know the details yet. -- Option 2 -- The other option I could think of is to generate a .edc file from the front end as normal along with the .s file, then run the assembler to produce the .o file from the .s file, and then get the driver to run some "embedding compiler" program that uses libbfd to embed the .edc file into the .o file before it is passed onto the linker. This could be a more "generic" approach that could be used elsewhere for embedding meta-data into object files using gcc, thought I am not sure of the details yet. This "embedding compiler" would simply place meta-data into object files using libbfd and would be driven by the gcc driver. I have never used libbfd before, and from what I understand it would still have the same problems of needing to decide which section to place the meta-data into. Where would be the best section to place this sort of data? Also does using ar/ld on resulting .o files filter out any sections they don't know about? Or do they always just include sections into the resulting archive/executable even if the sections are non-standard containing meta-data that they don't understand? Sorry for the emails, I just find it helpful discussing these issues with others. It has produced great results so far in the idea of embedding the meta-data into the .o files and I am fairly new to compiler development and so don't understand this stuff completely. Thanks, Brendon.
