I don't have an XP environment and I don't think this bug is worth setting one up. I can provide a way to filter the pseudostack in cleopatra which will throw away the pseudo frames when viewing a profile. This will solve this use case. Since we would only filter the frames we will still retain the pseudoframes so if it carries important information it can still be looked up.
My guess is XP doesn't return the correct SPs when unwinding causing the merging to fail.

(In reply to Benoit Girard (:BenWa) from comment #1)
> I don't have an XP environment and I don't think this bug is worth setting
> one up. I can provide a way to filter the pseudostack in cleopatra which
> will throw away the pseudo frames when viewing a profile. This will solve
> this use case. Since we would only filter the frames we will still retain
> the pseudoframes so if it carries important information it can still be
> looked up.
>
> My guess is XP doesn't return the correct SPs when unwinding causing the
> merging to fail.
I'm confused. The BaseProcessStart bits (native, IIUC?) aren't particularly negligible in terms of total profile time, but not the majority (AFAICT). By extension, I guess this means the pseudostacks are the majority, which means we'll lose a lot of data this way, won't we?
I'm also confused why this bug doesn't seem worth setting up an env. Is it unlikely that the bug can be fixed if your guess proves right, or is it just that XP doesn't seem like a platform worth investing time into, or...?

The profiler collects a Pseudostack and a native stack (where possible). The problem is we incorrectly merge them but the information collected is accurate. The pseudostacks aren't the majority, they just replicate (and sometimes extends) the information collected by the native stack.

For future reference:
The Gecko Profiler didn't display pseudo-stacks properly on Windows XP because StackWalk64 wasn't unwinding the SP stack past the first frame on XP. Installing a newer version of dbghelp.dll fixed the issue.
The XP SP3 version of dbghelp.dll (v5.1.2600.5512) isn't recent enough. You can get a more recent version from the Visual Studio install directories, e.g. dbghelp version 6.12.2.633 which comes with Visual Studio 2010. Copy it over to System32 or next to firefox.exe

Placing a newer version of dbghelp.dll into the running Firefox directory fixed this issue for me.
I *believe* the copy of dbghelp.dll I have is redistributable, since it's not the copy that shipped with my copy of Windows.
Because of this, I've posted this file here in case more people run into this problem: http://people.mozilla.com/~mconley2/sps/dbghelp.dll
Again, just place that into the directory that Firefox is running out of, and your native / pseudostacks should interleave properly.

So, just to sum up the best course of action to work around this bug:
1) Go here: http://go.microsoft.com/fwlink/p/?linkid=84137
2) Download the latest copy of Debugging Tools for Windows supported by your system
That *should* do it. If for some reason it doesn't, find the dbghelp.dll file that the above installation pulled into your system, and drop it into your Firefox directory.

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> Can we redistribute this DLL through the Gecko Profiler add-on?
That'd probably be ideal, but I'm no lawyer, and I really have no idea what the rules are here.
Gavin - you mentioned to me via e-mail that it's probably OK to redistribute the DLL if it's part of a software package. The Profiler Add-on probably counts, doesn't it?