@gasche I would like this to go into 4.06. Without it you cannot use spacetime.

We would need a proper review for this, which I can't give myself. (I don't understand what this change for people that do not use spacetime, which is necessary to assess the riskyness of the change.)

On the negative side:

• I find it a bit weird that so much functionality is duplicated because "SPACETIME_PROFINFO" and "PROFINFO".
• if I understand correctly, Spacetime was already broken in the 4.05 release (which includes @lefessan's patch) -- this woud limit my personal guilt if 4.06 happened to remain broken
• We would also have the option of reverting Add --profinfo XX to ./configure #735 in 4.06 instead of merging more last-minute fixes (I think @lefessan's idea of a more general entry for both ocp-memprof and spacetime is nice, but for now it seems to not be working so well).

We would need a proper review for this, which I can't give myself. (I don't understand what this change for people that do not use spacetime, which is necessary to assess the riskyness of the change.)

Yeah. I think Mark is back from vacation tomorrow, so we should be able to get a review soon. I just wanted to make sure you were aware of this PR.

I find it a bit weird that so much functionality is duplicated because "SPACETIME_PROFINFO" and "PROFINFO".

Possibly some of it can be shared, but of course cpp macros aren't the easiest things to create abstractions with.

if I understand correctly, Spacetime was already broken in the 4.05 release (which includes @lefessan's patch) -- this woud limit my personal guilt if 4.06 happened to remain broken

What was broken was any spacetime viewer compiled with 4.05. A spacetime viewer compiled with 4.04 could still read profiles made by programs compiled with 4.05. However, 4.06 adds to the spacetime profile format (see #1180), so a 4.04 viewer will not be able to read profiles created with 4.06 -- indeed no viewer will.

We would also have the option of reverting #735 in 4.06 instead of merging more last-minute fixes (I think @lefessan's idea of a more general entry for both ocp-memprof and spacetime is nice, but for now it seems to not be working so well).

That doesn't really seem necessary. It's only a small bug in that PR, and I think ocp-memprof is using the functionality.

(The CIs are failing right now.)

The new variable SPACETIME_PROFINFO_WIDTH needs to be added to the four config/Makefile.m* files to fix AppVeyor.

It looks strange to me that you are defining a configure variable that cannot be changed by the user (or anything else, for that matter). It's just a constant!

That's the simplest way I could see to allow the value of that constant (spacetime_profinfo_width) to be specified only a single time: it is used as the value of profinfo_width when spacetime is set to true.

This very much looks like a cross-compilation problem and not strongly tied to spacetime: any other profiling tool will encounter the same difficulty, right?

It's a kind of cross-compilation problem. Certainly any profiling tool needs to distinguish between the code for profiling the current program and the code for reading profiles. Unfortunately someone changed a part that was being shared between those two bits of code (ignoring a comment right next to it saying that it was shared).

A possibly cleaner approach would be for profiles themsleves to include the profinfo_width inside them. That's what happens with the genuine configuration option spacetime_call_counts. I'd be happy to do it that way, as long as people don't mind waiting a couple of days for the PR.

I'd like to see the cleaner approach. We can afford a few days.

Ok I've written a version that's half-way to what I described as the "cleaner approach". It no longer tries to define the "spacetime_profinfo_width" in configure, I was doing that to try and define it in a single place but with the windows Makefiles it was already spread across 5 places anyway. Instead spacetime_offline.c includes:

#define SPACETIME_PROFINFO_WIDTH 26

In the future we could put the width into the profile itself and pass it from there through to the functions in spacetime_offline.c (the "cleaner approach"), but for now I've just hard coded it here as that avoids us having to change the spacetime profile format.

To take account of Gabriel's comment I've also defined versions of PROFINFO_SHIFT, PROFINFO_MASK and Profinfo_hd that take the width as a parameter, and used those for defining the versions using PROFINFO_WIDTH and SPACETIME_PROFINFO_WIDTH.

@damiendoligez What do you think of the new version?

Merged and cherry-picked onto 4.06 (ef8844f)