colden (Colden Cullen)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 20 2017, 12:14 PM (8 w, 1 d)

Recent Activity

Today

colden added inline comments to D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).
Tue, Jan 16, 9:26 AM
colden added a comment to D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).

Bump, could someone submit this for me?

Tue, Jan 16, 9:18 AM

Fri, Jan 12

colden added a comment to D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).

Thanks for the quick reviews!

Fri, Jan 12, 4:50 PM
colden updated the diff for D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).

Turns out you can do the easier thing

Fri, Jan 12, 4:42 PM
colden updated the diff for D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).

Switch error message to use decimal format from hex.

Fri, Jan 12, 4:20 PM
colden added inline comments to D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).
Fri, Jan 12, 3:30 PM
colden created D42010: [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB).
Fri, Jan 12, 1:56 PM
colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

Thank you Zach!

Fri, Jan 12, 1:44 PM

Thu, Jan 11

colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

Ping, could someone please submit this for me?

Thu, Jan 11, 1:33 PM

Wed, Jan 10

colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

If you wouldn't mind committing this for me, I'd really appreciate it.

Wed, Jan 10, 9:54 AM
colden updated the diff for D41825: [Docs][PDB] Update MSF File documentation.

nth time's the charm!

Wed, Jan 10, 9:04 AM
colden added inline comments to D41825: [Docs][PDB] Update MSF File documentation.
Wed, Jan 10, 8:46 AM

Tue, Jan 9

colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

Updated with my newer, better understanding of the file layout

Tue, Jan 9, 6:09 PM

Mon, Jan 8

colden updated the diff for D41825: [Docs][PDB] Update MSF File documentation.

Now that I actually understand how the intervals work, I reworked a lot of what I had written. I think it's much clearer now, but I'm sure there's more nits to be had :)

Mon, Jan 8, 11:45 AM
colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

So each interval has exactly 4096 blocks. Block 0 is only special in the first interval. It's still there in every other interval, it just contains regular data.

But according to the code, that can't be true. Specifically, I'm looking at llvm::msf::getFpmStreamLayout. If you look at the loop assuming that FpmBlock is 1, then it pushes index 1 as the first FPM block, adds the result of msf::getFpmIntervalLength (which always returns 4096), and pushes that. This means that the second FPM in the sequence is at index 4097, which would mean that there are 4097 blocks in front of it. Unless block at index 4096 is unused, the first interval is in fact 1 block longer.

Doesn't all of that match up exactly with the layout I posted? Paste a copy of that layout diagram in my previous comment onto the end of itself. 4096 becomes "Data", 4097 becomes "FPM1", 4098 becomes "FPM2". "Interval" is the distance between two consecutive blocks of the same FPM. It's always 4096. So FPM1 is on blocks 1, 4096 + 1, 4096*2 + 1, 4096*3 + 1, etc. The blocks immediately before that (0, 4096, 4096*2, 4096*3, etc) are just data, with the only exception being block 0, which is the super block.

Mon, Jan 8, 10:49 AM
colden added a comment to D41825: [Docs][PDB] Update MSF File documentation.

So each interval has exactly 4096 blocks. Block 0 is only special in the first interval. It's still there in every other interval, it just contains regular data.

But according to the code, that can't be true. Specifically, I'm looking at llvm::msf::getFpmStreamLayout. If you look at the loop assuming that FpmBlock is 1, then it pushes index 1 as the first FPM block, adds the result of msf::getFpmIntervalLength (which always returns 4096), and pushes that. This means that the second FPM in the sequence is at index 4097, which would mean that there are 4097 blocks in front of it. Unless block at index 4096 is unused, the first interval is in fact 1 block longer.

Mon, Jan 8, 10:40 AM
colden added inline comments to D41825: [Docs][PDB] Update MSF File documentation.
Mon, Jan 8, 10:26 AM
colden created D41825: [Docs][PDB] Update MSF File documentation.
Mon, Jan 8, 8:50 AM

Fri, Jan 5

colden added a comment to D41742: [MSF] Fix FPM interval calculation.

Oh hey also, should this go in 6.0?

Fri, Jan 5, 9:28 AM

Thu, Jan 4

colden accepted D41742: [MSF] Fix FPM interval calculation.

I'm assuming you'll want approval from someone else too, but this looks good to me, and is proven to fix my bug.

Thu, Jan 4, 4:58 PM
colden added inline comments to D41742: [MSF] Fix FPM interval calculation.
Thu, Jan 4, 4:39 PM
colden added inline comments to D41742: [MSF] Fix FPM interval calculation.
Thu, Jan 4, 4:00 PM
colden added inline comments to D41742: [MSF] Fix FPM interval calculation.
Thu, Jan 4, 3:47 PM
colden added a comment to D41742: [MSF] Fix FPM interval calculation.

Makes sense! Thanks for adding a test btw.

Thu, Jan 4, 3:33 PM
colden abandoned D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

Abandoned in favor of D41742.

Thu, Jan 4, 3:29 PM
colden added a comment to D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

Yeah, that's the callstack I'm seeing. And I'm all for as many asserts as we can add to guarantee safety.

Thu, Jan 4, 1:55 PM
colden added a comment to D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

Just kidding it already does that?

Thu, Jan 4, 1:32 PM
colden added a comment to D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

OOOOH That makes so much sense. I was wondering how you could have 2 FPMs at the start but only one every stride after that, but never connected that to this...

Thu, Jan 4, 1:31 PM
colden added a comment to D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

In the process of writing this comment, I rewrote it like 8 times whenever I discovered something. So sorry if this reads disjointly :)

Thu, Jan 4, 1:19 PM
colden added a comment to D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.

This actually took me 3-4 days to track down, but I'll try to explain as clearly as I can :)

Thu, Jan 4, 11:04 AM
colden created D41734: [DebugInfo][PDB] Fix too many FPM blocks being written in some cases.
Thu, Jan 4, 10:37 AM

Dec 13 2017

colden added a comment to D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic.

Thanks Reid! Would you mind submitting this for me?

Dec 13 2017, 2:01 PM
colden added a reviewer for D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic: agutowski.
Dec 13 2017, 10:44 AM

Dec 12 2017

colden added inline comments to D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic.
Dec 12 2017, 4:02 PM
colden updated the diff for D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic.

llvm::IntegerType::get(getLLVMContext(), 128) -> Builder.getInt128Ty()

Dec 12 2017, 4:01 PM
colden updated the diff for D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic.

Moved implementation to X86_64 specific code, as according to Microsoft docs this function isn't supported on X86 or ARM.

Dec 12 2017, 2:38 PM

Dec 8 2017

colden created D41032: [CodeGen][X86] Implement _InterlockedCompareExchange128 intrinsic.
Dec 8 2017, 1:55 PM