rems-project / linksem Goto Github PK

In dwarf.lem there are some "missing pervasives" called natural_nat_shift_left and natural_nat_shift_right with no definition but with OCaml bindings. Are these equivalent to multiplication and division by a power of 2? If so, could they be defined that way, at least for the HOL backend?

Why is it that 5ec62e5 only disables this check for elf64 and not for elf32?

If I understand correctly from the elf specification this check should occur for PT_LOAD segments but not for other types.

For examle: PT_LOPROC does have filesz > memsz in an elf32-littleriscv compiled with the riscv-gnu-toolchain which is not against the specification in my understanding.

The next perf bottleneck is write_natural_field. I thought byte_sequence was used in memory images, but it turns out this is used instead:

type byte_pattern_element = maybe byte
type byte_pattern = list byte_pattern_element

(* An element might have an address/offset, and it has some contents. *)
type element = <| startpos : maybe natural
                ; length   : maybe natural
                ; contents : byte_pattern
                |>

Is there a reason why we use maybe byte instead of byte here?

Since element is used 140 times in the whole codebase, replacing it with something else is possible but definitely not trivial.

In Archive.accum_archive_contents, the first line computes the byte sequence length:

This is a performance bottleneck: by removing it, execution time goes from 17s to 11s on a glibc-linked hello world.

I wonder what's the best way to deal with it:

• Make the ocaml target omit the check somehow? Maybe there's a way to disable asserts with release builds?
• Switch Byte_sequence to be backed by an array instead of a list for the ocaml target. This will probably increase performance on the whole codebase, not sure how tricky it is.

Commit 81afd2f was committed to support riscv-32 test elf files but we're not exactly sure why it was required. Once we have a diagnosis we should implement a proper fix.

Would prevent some namespace pollution in https://github.com/rems-project/read-dwarf

Why does auto_generated/hol specify -kananaskis-10? Is there something specific about the process which fixes it to that release? I can't see any such thing. I notice that the coq and isabelle directories are simply named without a version, and I would suggest the same convention for hol.

Up until a few days ago everything worked with OCaml 4.02.3, which is the OCaml version supported by rmem.

When I try to build linksem (make LEM=<path_to_lem>) with OCaml 4.02.3 I get this:
[..]
File "byte_sequence_wrapper.ml", line 77, characters 2-11:
Error: Unbound value List.init
[..]

(List.init was introduced in 4.06.0)

Best,
Shaked

Building linksem produces lots of {cmi,cmo,cmx,ml,o} files -- could these be gitignored?

Please change the default to no_ocamlbuild.

Doing make hol-extraction under src produces the following error:

File "dwarf.lem", line 131, character 19 to line 131, character 31
  Type error: unbound variable for targets {hol}: print_endline
lem.mk:165: recipe for target 'hol-extraction' failed

This seems to be a debugging feature, so perhaps it could be excluded from the extraction to provers?
From the Lem library:

(* debugging functions; these should *not* be used in production code,
   but are invaluable in debugging the OCaml extraction, as long as

And the uninstall target, of course.