enable UUID for pbc

[rurban]

With r36890 I've enabled UUID stamping of pbc's for the t/native_pbc/ tests. tools/dev/pbc_header.pl --upd works now again.

In order to enable UUID's (uuid_type=1) for all PBC's I plan the following:

• read the UUID, the md5 fingerprint of PBC_COMPAT with Parrot::BuildUtils::generate_pbc_fingerprint() at Configure.pl

• uuid_size = 12, so that the new padding in the header will be 2 instead of 14 and the header size before the directory stay the same.

• store the pbc_fingerprint as PBC_UUID in config.h for packfile.c

• write every pbc with this UUID

• check the UUID when reading pbc's and warn when reading incompatible PBC's, different UUID's.

• error on reading newer bytecode versions, allow reading older versions. That was the original intention at least.

[rurban]

Attached is an actual proof-of-concept patch.

Sample:

config.h: 
#define PARROT_PBC_UUID         "îø=êš„˜:ª" 

config_lib.pasm:
    set P0["pbc_uuid"], "îø=êš„˜:ª"

• Not binary safe? Or use md5_base64 with 22 bytes instead of 12. This requires a larger header. Currently we just the spare padding, which went from 14 to 2 bytes.

./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
Malformed string

pbc_uuid is calculated in auto::pmc, after auto::ops, and incooporates on user-defined pmc and ops those, plus the bc_major, bc_minor from PBC_COMPAT.

What should else should be taken into the uuid? I just have the pmc and ops names plus bc version, but in reality all the public interfaces are needed also.

Two generic pbc functions are moved to Parrot::BuildUtil, get_bc_version() and generate_pbc_fingerprint(). This simplifies dev/pbc_header.pl and tools/build/pbcversion_h.pl.

[rurban]

md5 not binary safe?

[rurban]

binary safe 22 byte UUID (base_64)

[rurban]

I have two questions and a proposal about our pbc policy, when we encounter a bc version mismatch and with this path a UUID mismatch.

Proposal: use the Parrot_pbc_read() options to seperate parrot from the pbc_utils.

• parrot, pbc_to_exe and pbc_merge should fail with a "Incompatible packfile" error, when we know that it will fail: UUID and bc version mismatch. option=0

• however, the other parrot_utils, pbc_dump, pbc_info, pbc_disassembler, parrot_debugger should only warn when reading old pbc's, esp. on a UUID mismatch. option=1

Should we be strict, as currently, or relaxed as promised as original pbc design goals? It was even designed to be more cross-version portable as I remember.

Should our deprecation policies handle this in the code? - change the uuid and bc version but keep portability for two releases.

[rurban]

With the tt359-pbc_uuid.2.patch I misunderstood the original purpose of uuid. It should be the md5 of the pbc which is created. I'll have to update this in a new patch.

However, we still have the open problem of cmdline configured sets --ops and --pmc. Should we handle this also with a custome UUID as I did in the patch above? Or get rid of this feature.