Fixes #2966 and #2967: Ensure DRCOV unique IDs and max 4GiB ranges.

[forky2]

No description provided.

[tokatoka]

can you run ./scripts/fmt_all.sh?

[rmalmain]

thanks for the issues and the pr.
the reason why we merged the ranges in one module is to make the drcov files work in external tools like this one.
it does not support multiple modules with the same path atm.
but i guess sometimes it's not possible to avoid cases like #2966 or #2967.
we can merge this since it fixes a bug while not breaking the compatibility with the other tool in most cases.

[domenukk]

Maybe add a max_module_size flag that ppl can set if they want to, or ... not?

Who has >4gb modules anyway?

[forky2]

Maybe add a max_module_size flag that ppl can set if they want to, or ... not?

Who has >4gb modules anyway?

I do unfortunately. In performing qemu fuzzing against a custom target that loads an interesting coredump into memory, >4GiB regions are not only possible, but likely.

Regardless my particular odd case, isn't the way the RangeMap works is to coalesce ranges? i.e. if I have liba.so with a mapping in 0x1000-0x2000, and a mapping at 0x7fffffff'00001000-0x7fffffff'00002000, then it merges into one big 0x1000-0x7fffffff'00002000 range, doesn't it? Or am I wrong on that?

[WorksButNotTested]

Maybe add a max_module_size flag that ppl can set if they want to, or ... not?

Who has >4gb modules anyway?

The DrCov format records each record as a tuple containing:

• a module id
• a length
• an offset from the base of the module (referenced by the module ID)

Therefore should a single module span more than 4Gb, then it is not possible to represent its coverage without overflowing the offset field. Therefore 4Gb is a hard limit imposed by the underlying format. Whilst most tools don't support repeated entries for the same module name, the specification doesn't explicitly prohibit it and at least the file is capable of representing the coverage data in this case.