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
