1348154 - Compilation order affects results

Status: NEW

(Core :: JavaScript: GC, enhancement, P3)

Description

[Steve Fink [:sfink] [:s:]]

We compile jemalloc multiple times, with different versions. The later compilations overwrite the earlier in the xdb files.

While supporting incremental compilation is great, it would be best if the full path to the source file was taken into account, instead of just the function name.

This seems difficult to implement, but I wanted to get a bug on file.

Comment 1

[Brian Hackett [Laid off!]]

The bare function name is used if the function has C linkage, so if there are multiple functions with the same linker name being compiled then we would need to understand what the linker is doing in order to figure out which version of the function is being referenced in different places.  That's outside the scope of what the sixgill frontend does, but a conservative approach would be to keep track of all the functions with the same linker name and lump them together when doing analysis.  This could be done but we'd have to diff the contents of each function to see if we have a new version when merging compiled functions into the xdbs and that could be expensive.

Comment 2

[Steve Fink [:sfink] [:s:]]

I'm not sure why C linkage is relevant here? An identical mangled name would also be order-dependent. Or maybe I just didn't explain things clearly, since I think we're saying pretty much the same thing.

The issue is that we can get different results depending on compilation order. Since most analyses are necessarily conservative (eg a function pointer must be assumed to call anything at all), the obvious safe fix would be to use the union of the callgraph for all separately-compiled functions with the same name (whether C or C++ linkage). But that requires getting all versions into the xdb files, which means either (1) expanding the function table key to include a filename as well as the function name, (2) merging identically-named functions in the xdb, or (3) having the xdbs represent a multimap instead of a map.

If you wanted to preserve incremental compilation, you would need to either remember the filename (or some key to the compilation unit) along with the function (whether keying off of it or not), do some smart merging in the xdb that would handle identical functions coming in, or just let things pile up in the xdb. I think you were suggesting #2?

Oh, and keying things off the compilation unit has the potential of bloating the xdbs for every copy of every function defined in a header file, which is maybe why you are thinking of #2.

At any rate, all of these options sound like way more work than they're worth, given that this is a niche case that has barely showed up so far.