Shawn Walker writes: > On Jun 16, 2009, at 2:22 PM, James Carlson wrote: > > By having the compiler store hashes into the object, you could > > independently verify that a given object was indeed produced from an > > unaltered set of sources without actually needing or having access to > > those sources. The fact that pkg(5) can verify the files on a given > > system is irrelevant; the user who has that object file alone doesn't > > necessarily have access to the system where it was built. > > > If the hash you're talking about can be placed into one of these > sections: > > .SUNW_signature > , .comment > , .SUNW_ctf, .SUNW_dof, .debug, .plt, .rela.bss, .rela.plt, .line, .note > > ...then pkg(5) can automatically ignore it when determining whether to > redeliver a file that hasn't otherwise changed and so that's probably > fine. However, Bart or Danek might have a clearer picture of things.
I think putting it in an ignored section makes some sense -- if it's the same .text and .data segment contents, then it's the same code and header file changes (if any) just do not matter. But that's pretty far afield of what we were discussing, which was how to examine a .o file and figure out which .h files were used in its production. That's something the compiler folks are keenly interested in, as it figures into their support model: they need to be able to reproduce problems that users see, and knowing what files were used to produce a given .o file is key in doing that. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
