let-def / owee Goto Github PK

Hey Fred,

what a great library. Would you mind to cut a release? the most recent one (0.3) in opam-repository does not include support for OCaml 4.12+.

Thanks,

Hannes

Thanks for doing this, it seems very handy!

I'm not able to get exposed functions in Owee_location to do... anything. I'm sure I'm doing something simple incorrectly.

Would it be possible to add a usage of Owee_location to examples?

This would both help as a starting point for usage and, if there is indeed something wrong, would help me begin debugging.

It saddens me, but GCC now defaults to DWARF v5. It would be nice to support it in Owee otherwise its going to be a PITA... Well, a brief overview of the DWARF 5 standard definition tells me it is going to be a PITA either way.

Can be clearly seen when applying functions on itself

% ./_build/default/functions.exe _build/default/functions.exe | head
All symbols:
0 (function)
65 (function)
dlib__55 (function)
r_tm_clones (function)

sh_1010 (function)
mat__58 (function)
rray__size_in_bytes_1328 (function)
ring__rindex_from_opt_1173 (function)

Looking at it with nm, it's pretty clear some names are truncated.

Currently, a dune utop results in:

File "_build/default", line 1, characters 0-0:
ld: error: undefined symbol: caml_startup__code_begin
>>> referenced by owee_stubs.c:47
>>>               owee_stubs.o:(ml_owee_code_pointer) in archive src/libowee_stubs.a

ld: error: undefined symbol: caml_startup__code_end
>>> referenced by owee_stubs.c:47
>>>               owee_stubs.o:(ml_owee_code_pointer) in archive src/libowee_stubs.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
File "_none_", line 1:
Error: Error while building custom runtime system

Even for projects that depend on owee. It would be great to support bytecode targets, even if understandably owee woudn't work as expected. In the meantime we had to comment out the packages using owee to get an interactive session up and running.

Owee_debug_line.read_chunk now takes an additional ~pointers_to_other_sections argument.

Hi!

While working on magic-trace, we found that we spend a long time (~20-30 seconds) loading some decently-sized binaries with Owee. These binaries have ~2 million symbols.

I captured a ~1ms trace of this:

It's all in building Owee_interval_trees.

I think we can build it substantially quicker while maintaining query speed, since we have the advantage of knowing up front all the symbols (such that we never have online interval additions), and we have functional maps. (Thanks @FatalEagle for much help with the algorithm here.) We would be building a sort of "prefix sum of maps".

Below is some simple pseudocode for replacing Owee_interval_tree, while allowing it to be built much faster:

type t = {
   maps : Map[left bound int, Map[right bound int, symbol]]
   ; cumulative_right_bound_to_interval_map : Map[right bound int, symbol]
}

fun build intervals:
    maps = {}
    cumulative_right_bound_to_interval_map = {}

    for ({ symbol = _, left, right } as interval) in intervals sorted by nondecreasing left bound:
        (* This step is "free" thanks to functional maps *)
        cumulative_right_bound_to_interval_map |= { right: interval }
        maps[left_bound] = cumulative_right_bound_to_interval_map

    return { maps; cumulative_right_bound_to_interval_map }

fun iter f:
    map(f, cumulative_right_bound_to_interval_map.values())

fun query addr:
    (* O(log n) time, n = size of [maps]
     * This is implementable with closest_key `Less_or_equal_to
     * https://ocaml.janestreet.com/ocaml-core/v0.12/doc/base/Base/Map/index.html#val-closest_key *)
    right_map = binary search maps for greatest left bound <= addr
	
    (* O(log n) time, n = size of [right_map]
     * This is implementable with [to_sequence ~lower_bound:<bound from above> ~upper_bound:addr]
     * https://ocaml.janestreet.com/ocaml-core/v0.12/doc/base/Base/Map/index.html#val-to_sequence *)
    return (right_map filtered for right bound >= addr).values()

The catch here is that while query is conceptually simple, closest_key and to_sequence are not provided in the standard library. Are we willing to take a dependency on Base here?