LabVIEW
Reading object file (.o file) using labview
Hi Anand,
@AnandR wrote:
I am trying parse the object file using labview like reading section and symbol table.
I thought doing this using Labview is easier and user friendly.
It can be easy - when you know how to parse that object file!
Do you know all the details of the fileformat? (This information is needed to parse the file…)
Hi Anand,
@AnandR wrote:
I am not exactly sure how internals of object file organized. I was trying to understand this by reading through labview.
There are many difficulties with this. Since you use the .o extension you most probably are trying to read Linux ELF compiled object formats. On Windows those files are usually called .obj. But as with anything file ending related, it's a convention and not a standard enforced by any specifc consortium.
Now all object files are fully binary in essence. They contain the compiled assembly code instructions for a particular target. In order to be able to understand where and how these assembly code block are stored it also contains various headers that reference each other. There is some main header, then there are various sub headers each with their own format and pointing to other entries describing various resources in the object file, one of them being the compiled code blocks. All of this information is binary and there are many different object file formats. ELF is the standard nowadays on Linux systems but there are several others from earlier Unix versions that are just as valid. On Windows you have the Microsoft sponsored COFF format and the nowadays less used OMF format which was the prefered format used by IBM and also the predominant format for all Borland products. Each of these formats is fairly different in how the various headers are formatted and what information it specifically contains, despite them all having the same purpose.
So if you want to read your .o file you first have to find out what format it really uses and then read through the format specification and locate the different header parts in the file by starting at the main header, decoding its binary information, locate the subheaders, decoding their binary information and so on. Possible in LabVIEW? Absolutely! Easy? Absolutely not and that has nothing to do with LabVIEW. Decoding and interpreting binary file formats is difficult, hard, cumbersome and riddled with many problems, including having to interpret the standard describing the format and guessing and try and error if your interpretation is correct. Even if it finally works for your first file, changes are very big that it will file for the next one as some of your interpretations are wrong under certain conditions or simply because the standard was written at some point, but the real world implementation has never been like that or deviated from that standard in the mean time. If a company like Microsoft implements something in a certain way, you can have 100ds of standardization documents saying it should be otherwise, but the simple dominance of that implementation creates quickly a defacto standard, no matter how much it violates the official standard.
A typical process to read such files would be to read a header at the beginning or a well known offset in the file and check that there is a certain signature (byte sequence) that indicates the format. Once you have confirmed that this signature is present you can with a fair certainity assume that you have the expected file in front of you. Then read the main header which is usually at a fixed offset in the file based on the previous format signature check and decode it. There will be various identifiers in this record that are binary in nature and can be bytes, words, integers, or long words that tell you things like the version number of the format, the code architecture for which this object file was created, special compile configuration and last but not least pointers (offsets) into the file to other records such as the import and export table. Each table is usually an array of identifiers and offsets into the file that point at other records describing each entry and that entry contains again offsets that can point at the actual code junks for the exported function. For imports it can contain offsets into the code chunks at which the import must be patched into when loading the object file. Very complicated, very cumbersome, and VERY easy to make errors. So if you thought it would be easy to do something like that in LabVIEW you were completely wrong. Not because LabVIEW can't do it but simply because it is a pain in the @ss to do, no matter in which programming language you try to work. LabVIEW has a little advantage here actually compared to other approaches like using C, in that you don't have to worry about doing memory management right before you can worry about trying to decode the information. That makes it all a bit easier but it is still a very tedious and painful exercise that you only want to do for two reason:
1) There is a commercial interest to do it and using existing command line tools that already do it is not a good option.
2) You like to tinker with binary file decoding simply for the fun of it. But even then there are more interesting things than trying to decode object file formats, such as image formats for instance.
