profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/vedantk/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

llvm/llvm-project 10424

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

vedantk/gcrypt-example 20

libgcrypt example code

vedantk/evt-server 11

a simple, fast server framework for C

vedantk/auto-diagonalize 8

an LLVM optimization pass that diagonalizes linear dynamical systems

vedantk/53otron 4

jit compiler for vector expressions

vedantk/bptree 4

An in-memory B+ tree

vedantk/CodeGenWorkshop 4

code generation with llvm

folz/Calculus-Blasters 3

Explode asteroids and solve calculus word problems the fun way!

michelle/hackberkeley 3

hackers@berkeley website

hbradlow/em_hole_finder 2

Computes masks of carbon holes in electron micrographs.

delete branch apple/llvm-project

delete branch : cherry-82679400-to-20210726

delete time in 4 days

push eventapple/llvm-project

Vedant Kumar

commit sha 5966f3eb5785f9f1deb26f33c41e248646793281

[lldb][crashlog] Avoid specifying arch for image when a UUID is present When adding an image to a target for crashlog purposes, avoid specifying the architecture of the image. This has the effect of making SBTarget::AddModule infer the ArchSpec for the image based on the SBTarget's architecture, which LLDB puts serious effort into calculating correctly (in TargetList::CreateTargetInternal). The status quo is that LLDB randomly guesses the ArchSpec for a module if its architecture is specified, via: ``` SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture -> GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex ``` ... which means that the same crashlog can fail to load on an Apple Silicon Mac (due to the random guess of arm64e-apple-macosx for the module's ArchSpec not being compatible with the SBTarget's (correct) ArchSpec), while loading just fine on an Intel Mac. I'm not sure how to add a test for this (it doesn't look like there's test coverage of this path in-tree). It seems like it would be pretty complicated to regression test: the host LLDB would need to be built for arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a binary with an iOS deployment target. I'm open to other / simpler options. rdar://82679400 Differential Revision: https://reviews.llvm.org/D110013 (cherry picked from commit e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc)

view details

Vedant Kumar

commit sha 0f6e045a5eab7dfec10e1c9e1e6865f18882b205

Merge pull request #3270 from apple/cherry-82679400-to-20210726 [lldb][crashlog] Avoid specifying arch for image when a UUID is present

view details

push time in 4 days

PR merged apple/llvm-project

[lldb][crashlog] Avoid specifying arch for image when a UUID is present

When adding an image to a target for crashlog purposes, avoid specifying the architecture of the image.

This has the effect of making SBTarget::AddModule infer the ArchSpec for the image based on the SBTarget's architecture, which LLDB puts serious effort into calculating correctly (in TargetList::CreateTargetInternal).

The status quo is that LLDB randomly guesses the ArchSpec for a module if its architecture is specified, via:

  SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex

... which means that the same crashlog can fail to load on an Apple Silicon Mac (due to the random guess of arm64e-apple-macosx for the module's ArchSpec not being compatible with the SBTarget's (correct) ArchSpec), while loading just fine on an Intel Mac.

I'm not sure how to add a test for this (it doesn't look like there's test coverage of this path in-tree). It seems like it would be pretty complicated to regression test: the host LLDB would need to be built for arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a binary with an iOS deployment target. I'm open to other / simpler options.

rdar://82679400

Differential Revision: https://reviews.llvm.org/D110013

(cherry picked from commit e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc)

+1 -1

0 comment

1 changed file

vedantk

pr closed time in 4 days

PR opened apple/llvm-project

[lldb][crashlog] Avoid specifying arch for image when a UUID is present

When adding an image to a target for crashlog purposes, avoid specifying the architecture of the image.

This has the effect of making SBTarget::AddModule infer the ArchSpec for the image based on the SBTarget's architecture, which LLDB puts serious effort into calculating correctly (in TargetList::CreateTargetInternal).

The status quo is that LLDB randomly guesses the ArchSpec for a module if its architecture is specified, via:

  SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex

... which means that the same crashlog can fail to load on an Apple Silicon Mac (due to the random guess of arm64e-apple-macosx for the module's ArchSpec not being compatible with the SBTarget's (correct) ArchSpec), while loading just fine on an Intel Mac.

I'm not sure how to add a test for this (it doesn't look like there's test coverage of this path in-tree). It seems like it would be pretty complicated to regression test: the host LLDB would need to be built for arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a binary with an iOS deployment target. I'm open to other / simpler options.

rdar://82679400

Differential Revision: https://reviews.llvm.org/D110013

(cherry picked from commit e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc)

+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchapple/llvm-project

branch : cherry-82679400-to-20210726

created branch time in 4 days

delete branch apple/llvm-project

delete branch : cherry-82898146-to-20210726

delete time in 4 days

push eventapple/llvm-project

Vedant Kumar

commit sha 7b1f0cb5f36680c1e0f3f56c38cedf1a3162a21a

[MachCore] Report arm64 thread exception state A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state. For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'. As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers. rdar://82898146 Differential Revision: https://reviews.llvm.org/D109795 (cherry picked from commit 3b14d80ad4af303c9f7df189b8b7eee528d0ec8d)

view details

Vedant Kumar

commit sha 16eb777b09d6fb61f197de45d67e3204af0d1f2d

Merge pull request #3269 from apple/cherry-82898146-to-20210726 [MachCore] Report arm64 thread exception state

view details

push time in 4 days

PR merged apple/llvm-project

[MachCore] Report arm64 thread exception state

A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state.

For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'.

As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers.

rdar://82898146

Differential Revision: https://reviews.llvm.org/D109795

(cherry picked from commit 3b14d80ad4af303c9f7df189b8b7eee528d0ec8d)

+231 -10

0 comment

10 changed files

vedantk

pr closed time in 4 days

PR opened apple/llvm-project

[MachCore] Report arm64 thread exception state

A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state.

For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'.

As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers.

rdar://82898146

Differential Revision: https://reviews.llvm.org/D109795

(cherry picked from commit 3b14d80ad4af303c9f7df189b8b7eee528d0ec8d)

+231 -10

0 comment

10 changed files

pr created time in 4 days

create barnchapple/llvm-project

branch : cherry-82898146-to-20210726

created branch time in 4 days

delete branch apple/llvm-project

delete branch : cherry-82898146-82679400-to-20210726

delete time in 4 days

create barnchapple/llvm-project

branch : cherry-82898146-82679400-to-20210726

created branch time in 4 days

push eventllvm/llvm-project

Vedant Kumar

commit sha e31b2d7d7be98cbbaa665b2702cd0ed2975da4cc

[lldb][crashlog] Avoid specifying arch for image when a UUID is present When adding an image to a target for crashlog purposes, avoid specifying the architecture of the image. This has the effect of making SBTarget::AddModule infer the ArchSpec for the image based on the SBTarget's architecture, which LLDB puts serious effort into calculating correctly (in TargetList::CreateTargetInternal). The status quo is that LLDB randomly guesses the ArchSpec for a module if its architecture is specified, via: ``` SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture -> GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex ``` ... which means that the same crashlog can fail to load on an Apple Silicon Mac (due to the random guess of arm64e-apple-macosx for the module's ArchSpec not being compatible with the SBTarget's (correct) ArchSpec), while loading just fine on an Intel Mac. I'm not sure how to add a test for this (it doesn't look like there's test coverage of this path in-tree). It seems like it would be pretty complicated to regression test: the host LLDB would need to be built for arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a binary with an iOS deployment target. I'm open to other / simpler options. rdar://82679400 Differential Revision: https://reviews.llvm.org/D110013

view details

push time in 4 days

push eventllvm/llvm-project

Vedant Kumar

commit sha 3b14d80ad4af303c9f7df189b8b7eee528d0ec8d

[MachCore] Report arm64 thread exception state A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state. For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'. As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers. rdar://82898146 Differential Revision: https://reviews.llvm.org/D109795

view details

push time in 7 days

push eventllvm/llvm-project

Vedant Kumar

commit sha 79e48f3c7c8ca205048f584b7658ef001a677c6d

Revert "[MachCore] Report arm64 thread exception state" This reverts commit 7eb67748f9d7186419d678e807c01fc2a3811a80. It causes TestMachCore.MachCoreTestCase to fail.

view details

push time in 8 days

push eventllvm/llvm-project

Vedant Kumar

commit sha 7eb67748f9d7186419d678e807c01fc2a3811a80

[MachCore] Report arm64 thread exception state A MachO userspace corefile may contain LC_THREAD commands which specify thread exception state. For arm64* only (for now), report a human-readable version of this state as the thread stop reason, instead of 'SIGSTOP'. As a follow-up, similar functionality can be implemented for x86 cores by translating the trapno/err exception registers. rdar://82898146 Differential Revision: https://reviews.llvm.org/D109795

view details

push time in 8 days

startedalephsecurity/xnu-qemu-arm64

started time in 8 days

push eventllvm/llvm-project

Vedant Kumar

commit sha 66902a32c83809d26662f76e4107d5dd777610c3

[StopInfoMachException] Summarize arm64e BLRAx/LDRAx auth failures Upstream lldb support for summarizing BLRAx and LDRAx auth failures. rdar://41615322 Differential Revision: https://reviews.llvm.org/D102428

view details

push time in 10 days

push eventapple/swift

Vedant Kumar

commit sha ef9f6cbe54a1d8da1dbd389ab5b31c89ed4224a0

Revert "Fixup Coverage Mapping" (#39117) This reverts commit 40e420641041912dfa970ae9d7e5fcc9eee29aa0, due to rdar://82543962. It should still remain in effect on next.

view details

push time in 24 days

delete branch apple/swift

delete branch : rdar82543962

delete time in 24 days

PR merged apple/swift

Revert "Fixup Coverage Mapping"

This reverts commit 40e420641041912dfa970ae9d7e5fcc9eee29aa0, due to rdar://82543962. It should still remain in effect on next.

+3 -1

0 comment

1 changed file

vedantk

pr closed time in 24 days

create barnchapple/swift

branch : rdar82543962

created branch time in 24 days

PR opened apple/swift

Revert "Fixup Coverage Mapping"

This reverts commit 40e420641041912dfa970ae9d7e5fcc9eee29aa0, due to rdar://82543962. It should still remain in effect on next.

+3 -1

0 comment

1 changed file

pr created time in 24 days

push eventllvm/llvm-project

Vedant Kumar

commit sha 6c439a38172bbb3422b91517e69cd091ff34062c

[profile] Specify "-V" to otool to get expected test output Newer Xcode toolchains ship a new otool implementation that prints out section contents in a slightly different way than otool-classic. Specify "-V" to otool to get the expected test output. Differential Revision: https://reviews.llvm.org/D108929

view details

push time in 24 days

push eventapple/llvm-project

Vedant Kumar

commit sha 703a0ea940f2751d46ed3ba401c44108265356c7

Revert "[Coverage] Store compilation dir separately in coverage mapping" This reverts commit 5fbd1a333aa1a0b70903d036b98ea56c51ae5224. See: rdar://82543962 (Revert coverage changes from clang-1316 to make coverage format in clang-1316 identical to clang-1300) Testing: * check-profile passed before and after this revert. * check-clang reported 4 failing tests prior to this revert; that remains unchanged. Driver/clang_f_opts.c required a workaround. The coverage-compilation-dir.c test was xfailed. * check-llvm passed before and after this revert. The llvm-cov/compilation_dir.c test is now xfailed. Coverage unit tests pass with the exception of non_code_region_counters, which was disabled because https://reviews.llvm.org/D101780 was folded into this revert. Conflicts: clang/include/clang/Basic/CodeGenOptions.h clang/include/clang/Driver/Options.td clang/lib/CodeGen/CoverageMappingGen.cpp clang/lib/Driver/ToolChains/Clang.cpp clang/test/Profile/profile-prefix-map.c llvm/include/llvm/ProfileData/Coverage/CoverageMappingReader.h llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp llvm/unittests/ProfileData/CoverageMappingTest.cpp

view details

Vedant Kumar

commit sha f059854a0a4daf1833db64217bc2f59f6498caad

Merge pull request #3212 from apple/rdar82543962 Revert "[Coverage] Store compilation dir separately in coverage mapping"

view details

push time in 24 days

PR merged apple/llvm-project

Revert "[Coverage] Store compilation dir separately in coverage mapping"

This reverts commit 5fbd1a333aa1a0b70903d036b98ea56c51ae5224.

See: rdar://82543962 (Revert coverage changes from clang-1316 to make coverage format in clang-1316 identical to clang-1300)

Testing:

  • check-profile passed before and after this revert.
  • check-clang reported 4 failing tests prior to this revert; that remains unchanged. Driver/clang_f_opts.c required a workaround. The coverage-compilation-dir.c test was xfailed.
  • check-llvm passed before and after this revert. The llvm-cov/compilation_dir.c test is now xfailed. Coverage unit tests pass with the exception of non_code_region_counters, which was disabled because https://reviews.llvm.org/D101780 was folded into this revert.

Conflicts: clang/include/clang/Basic/CodeGenOptions.h clang/include/clang/Driver/Options.td clang/lib/CodeGen/CoverageMappingGen.cpp clang/lib/Driver/ToolChains/Clang.cpp clang/test/Profile/profile-prefix-map.c llvm/include/llvm/ProfileData/Coverage/CoverageMappingReader.h llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp llvm/unittests/ProfileData/CoverageMappingTest.cpp

+140 -199

0 comment

22 changed files

vedantk

pr closed time in 24 days

PR opened apple/llvm-project

Revert "[Coverage] Store compilation dir separately in coverage mapping"

This reverts commit 5fbd1a333aa1a0b70903d036b98ea56c51ae5224.

See: rdar://82543962 (Revert coverage changes from clang-1316 to make coverage format in clang-1316 identical to clang-1300)

Testing:

  • check-profile passed before and after this revert.
  • check-clang reported 4 failing tests prior to this revert; that remains unchanged. Driver/clang_f_opts.c required a workaround. The coverage-compilation-dir.c test was xfailed.
  • check-llvm passed before and after this revert. The llvm-cov/compilation_dir.c test is now xfailed. Coverage unit tests pass with the exception of non_code_region_counters, which was disabled because https://reviews.llvm.org/D101780 was folded into this revert.

Conflicts: clang/include/clang/Basic/CodeGenOptions.h clang/include/clang/Driver/Options.td clang/lib/CodeGen/CoverageMappingGen.cpp clang/lib/Driver/ToolChains/Clang.cpp clang/test/Profile/profile-prefix-map.c llvm/include/llvm/ProfileData/Coverage/CoverageMappingReader.h llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp llvm/unittests/ProfileData/CoverageMappingTest.cpp

+140 -199

0 comment

22 changed files

pr created time in 24 days

create barnchapple/llvm-project

branch : rdar82543962

created branch time in 24 days

delete branch apple/swift

delete branch : eng/PR-81815347-2

delete time in a month

push eventapple/swift

Vedant Kumar

commit sha 9066d9132ebb42727b6b8aa0cc58830fe3d0fa4d

Revert "[test] Fix a bug in test/Profiler/coverage_smoke.swift" (#38894) This reverts commit ebdb4d9ace39107d6912a572aaf4d10bd81871a8, due to https://reviews.llvm.org/D85036 being reverted upstream. rdar://81815347

view details

push time in a month