<div dir="ltr">MLton currently uses two functions, GC_getText{Start,End}, to create a giant lookup table for profiling. These two functions are among the hardest things to supply when porting MLton. It becomes even harder once shared libraries are considered, because then one needs to consider which text segment is intended. After reading the i386 sys v abi specification, I still have no idea how to do this correctly for shared libraries on elf.<br>
<br>It seems to me that not only are these a portability problem, they are completely unnecessary. Making a giant lookup table for every address in the text segment hardly seems like a worthy goal. I imagine the justification is that it has minimal impact on the performance of the program during handling of SIGPROF. However, I would contend that a giant lookup table could very well be more intrusive than just using a binary search of a compressed (repeated sourceSeqIndexes eliminated) sourceMaps.sourceLabels. Even if the binary search does have a greater impact, at 1kHZ it will hardly matter.<br>
<br>Of course this leaves open the interpretation of addresses before the first label and after the last label. As profiling labels are only used for i386/amd64 native codegens, any address before the first label is simply unknown. If the native codegens also emitted a label with a no-op at the end of each assembler file, this would neatly deal with addresses past the last label: the last label is unreachable anyway, so anything after it is unknown.<br>
<br>So to sum up: could I just kill these off and use a binary search?<br><br></div>