Yes I was aware of how it was exported, I just wasn't sure where it came from... But given that the only difference was the first word for each entry, I came to the conclusion that it must be being overwritten at runtime (given that the values are of course queried by the RTS). I just couldn't find where this was. Anyway, I shall try changing it to use bss for all three (pexport doesn't save it, so I hope even "make compiler" would be reproducible, although that's not an objective). This will also have the bonus of saving an incredible 8 or 16 KiB (depending on pointer size) on disk!..
Thanks, James > On 9 Mar 2016, at 18:58, David Matthews <[email protected]> > wrote: > > The "ioarea" is a piece of memory that is initialised by the run-time system. > It contains pointers to assembly code for run-time system calls, as well as > a few other things. I think what's happening is that the export function is > simply copying the current contents to the object file. It's going to be > overwritten when it's loaded so in a way it doesn't matter. See > https://github.com/polyml/polyml/blob/master/libpolyml/exporter.cpp#L496 . > > The rest of the object file can contain pointers to various locations in the > ioarea so there needs to be something that can be used as the target of > relocation entries. Possibly the correct solution is to use a bss > (uninitialised data) section. I think the reason it doesn't at the moment is > that there are three different "exporters", ELF, MachO and PECOFF and they > all do it differently. > > David > >> On 09/03/2016 16:56, James Clarke wrote: >> Hi, >> I’ve been working on making Poly/ML build reproducibly >> (https://reproducible-builds.org), specifically the Debian package, although >> it should be distro-agnostic. The first step was getting timestamps to be >> deterministic using SOURCE_DATE_EPOCH (see >> https://reproducible-builds.org/docs/timestamps/), and I have done this, >> both for libpolyml’s different export formats, and for PolyML.make. This was >> sufficient when disabling native code generation. However, using x86 native >> code generation, ioarea is not reproducible. Specifically, for every defined >> entry, the first word (which I believe is the length word?) differs, with >> the rest of the entry zero. An example (ioarea starts at 0x01029010; >> sizeof(PolyWord) is 8 and IO_SPACING is 8, so 0x01029050 is entry 1): >> >> 1 Hex·dump·of·section·'.data’: >> 1 Hex·dump·of·section·'.data': >> 2 >> ··0x01029000·00000000·00000000·08900201·00000000·................ >> 2 >> ··0x01029000·00000000·00000000·08900201·00000000·................ >> 3 >> ··0x01029010·00000000·00000000·00000000·00000000·................ >> 3 >> ··0x01029010·00000000·00000000·00000000·00000000·................ >> 4 >> ··0x01029020·00000000·00000000·00000000·00000000·................ >> 4 >> ··0x01029020·00000000·00000000·00000000·00000000·................ >> 5 >> ··0x01029030·00000000·00000000·00000000·00000000·................ >> 5 >> ··0x01029030·00000000·00000000·00000000·00000000·................ >> 6 >> ··0x01029040·00000000·00000000·00000000·00000000·................ >> 6 >> ··0x01029040·00000000·00000000·00000000·00000000·................ >> 7 >> ··0x01029050·cc495964·797f0000·00000000·00000000·.IYdy........... >> 7 >> ··0x01029050·cc1944ae·577f0000·00000000·00000000·..D.W........... >> 8 >> ··0x01029060·00000000·00000000·00000000·00000000·................ >> 8 >> ··0x01029060·00000000·00000000·00000000·00000000·................ >> 9 >> ··0x01029070·00000000·00000000·00000000·00000000·................ >> 9 >> ··0x01029070·00000000·00000000·00000000·00000000·................ >> 10 >> ··0x01029080·00000000·00000000·00000000·00000000·................ >> 10 >> ··0x01029080·00000000·00000000·00000000·00000000·................ >> 11 >> ··0x01029090·00000000·00000000·00000000·00000000·................ >> 11 >> ··0x01029090·00000000·00000000·00000000·00000000·................ >> 12 >> ··0x010290a0·00000000·00000000·00000000·00000000·................ >> 12 >> ··0x010290a0·00000000·00000000·00000000·00000000·................ >> 13 >> ··0x010290b0·00000000·00000000·00000000·00000000·................ >> 13 >> ··0x010290b0·00000000·00000000·00000000·00000000·................ >> 14 >> ··0x010290c0·00000000·00000000·00000000·00000000·................ >> 14 >> ··0x010290c0·00000000·00000000·00000000·00000000·................ >> >> Where are these coming from, and do you have any ideas for how to make sure >> they are reproducible? >> >> Regards, >> James >> >> >> >> _______________________________________________ >> polyml mailing list >> [email protected] >> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > _______________________________________________ > polyml mailing list > [email protected] > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
