John Carter wrote: thank you, John, seems you know what I mean as your recommendation is helpful. However, let me be a bit more specific, you may have more recommendations.
On Mon, 17 Jul 2006, Rolf Schumacher wrote:is it possible to code software in a style so that no bit of the object code changes even if referenced objects change?Hmm. I'm not entirely clear as to what you mean but here is some ideas that may or may not be relevant....Compile to position independent code. Reference no globals, const strings or statics.
O.k., fine. Position independent code would help. Also - in embedded systems - you can determine a fixed position for a module, even after changes. (module == some compilation units but not the whole software) But you're right, this is not the solution to the problem.
Somehow I suspect this is a case of, if we really knew which (larger) problem you were trying solve instead of what you are trying to do, their would be a much much easier way...
The larger problem: As an assessor for safety critical software of embedded systems I'm regularily faced with statements like: "we only have made a little change to the source code we do not want to retest all modules" The problem is, even if a change is made to one module only, how can I demonstrate that all other modules are unchanged? Put it a bit more technical: Unchanged source code is easy to demonstrate. But this is not the whole story. If I change the source of one module and recompile it, the relative and absolute addresses in that module will change. Any other module, that has references to the changed one, will change as well, at least after linking together. Additionally the absolute location of any other module may change after linking with the changed one, resulting in inner changes to that module (if the code is not location independent) Also if I recompile unchanged code, meta data (is there any?) could change that is contained in the object. As the tooling machines and the compiler itself is not safety approved errors could have been introduced in the unchanged, former tested modules. The only way to find these (unlikely) errors nowadays is to retest all modules. Or to ignore this problem with some unknown risk. But: retests are too expensive and risk negligence has its probability. The idea is to have a checksum for each module that has passed all tests successfully and this checksum is unchanged even if any other module becomes changed. It would help to have reference tables in between all modules, that may change all if one module changes but the modules themselves stay invariant. (Only one test for each table entry proves it to be correct.) That way you can rely on older module tests for old modules linked to a new software. Keeping it short: If an object modules checksum hasn't changed you haven't to retest it. I'm not a specialist for gcc, to be honest I do not know much about it, John, but I would like to point the developers to right direction. As such I would like to know if there is a chance of success on this subject prior to do the detailed investigation. Thanks for your kind help.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
