Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline

vadimcn (Vadim Chugunov)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 5 2014, 8:26 PM (504 w, 3 d)

Recent Activity

Oct 15 2021

vadimcn abandoned D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.
Oct 15 2021, 6:30 PM · Restricted Project

Oct 10 2021

vadimcn added a comment to D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.

Is it possible to get your IDE to record the module & the address?

Oct 10 2021, 6:24 PM · Restricted Project

Oct 8 2021

vadimcn added a comment to D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.

@JDevlieghere: ping. Or are you saying you wouldn't consider landing such a change at all?

Oct 8 2021, 2:18 PM · Restricted Project

Sep 15 2021

vadimcn added a comment to D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.

Hi Jim,
I think there's a bit of confusion going on here:
The original bug was opened by Ted Woodward, and I think his scenario was
motivated by embedded debugging. He also provided that example with a
breakpoint being set in main.

Sep 15 2021, 12:04 PM · Restricted Project

Sep 14 2021

vadimcn updated the diff for D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.

Added patch context.

Sep 14 2021, 11:12 PM · Restricted Project
vadimcn added a comment to D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.

In the future, can you generate patches with context (i.e. pass -U9999 to
"git diff" or "git show"), it's a lot easier to read patches with context.

Sure thing, will do.

Sep 14 2021, 11:10 PM · Restricted Project

Sep 13 2021

vadimcn requested review of D109738: [lldb] Fix bug 38317 - Address breakpoints don't work if set before the process launches.
Sep 13 2021, 8:48 PM · Restricted Project
vadimcn updated the diff for D109339: Fix compilation error with older libstdc++.

Re-formatted

Sep 13 2021, 8:21 PM · Restricted Project

Sep 6 2021

vadimcn requested review of D109339: Fix compilation error with older libstdc++.
Sep 6 2021, 4:55 PM · Restricted Project

Jul 21 2021

vadimcn added a comment to D100503: [lldb] [client] Implement follow-fork-mode.

@mgorny Do your changes allow debugging both the parent and child processes after a fork?

Jul 21 2021, 1:56 PM · Restricted Project

Jan 10 2020

vadimcn added inline comments to D67793: new api class: SBFile.
Jan 10 2020, 12:36 AM · Restricted Project, Restricted Project

Oct 14 2018

vadimcn committed rLLDB344474: Fix double import of _lldb module..
Fix double import of _lldb module.
Oct 14 2018, 12:27 AM
vadimcn committed rL344474: Fix double import of _lldb module..
Fix double import of _lldb module.
Oct 14 2018, 12:27 AM
vadimcn closed D52404: Prevent double import of _lldb module.
Oct 14 2018, 12:27 AM · Restricted Project

Oct 7 2018

vadimcn added a comment to D52404: Prevent double import of _lldb module.

Thanks,
What changed in SWIG 3.0.11?

Oct 7 2018, 12:19 AM · Restricted Project

Oct 6 2018

vadimcn added a comment to D52404: Prevent double import of _lldb module.

Changing title as it looks like this is not a Windows-only problem: https://github.com/rust-lang/rust/issues/54126.

Oct 6 2018, 9:03 PM · Restricted Project
vadimcn retitled D52404: Prevent double import of _lldb module from Prevent double import of _lldb module on Windows to Prevent double import of _lldb module.
Oct 6 2018, 8:21 PM · Restricted Project

Sep 18 2017

vadimcn added a comment to D37934: Fix compatibility with OpenOCD debug stub..

Maybe LLDB should use qAttached to determine if there's an active process? OpenOCD seems to implement that one correctly.

Sep 18 2017, 2:03 PM · Restricted Project
vadimcn added a comment to D37934: Fix compatibility with OpenOCD debug stub..

Sorry, for not catching this regression! I've checked that attaching to a standard gdbserver still worked, but was not aware of the other scenarios.

Sep 18 2017, 11:25 AM · Restricted Project

Sep 17 2017

vadimcn added a comment to D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump).

FYI - this broke at least Windows, because the default behavior of Process::WillResume() changed from success to an error and WindowsProcess does not override WillResume(). Not sure what other platforms are in the same boat.

Sep 17 2017, 12:54 AM

Sep 15 2017

vadimcn closed D37934: Fix compatibility with OpenOCD debug stub..
Sep 15 2017, 8:57 PM · Restricted Project
vadimcn closed D33855: Fix type category matching to source language..
Sep 15 2017, 8:56 PM · Restricted Project
vadimcn committed rL313442: Fix compatibility with OpenOCD debug stub..
Fix compatibility with OpenOCD debug stub.
Sep 15 2017, 8:54 PM
vadimcn added a comment to D37934: Fix compatibility with OpenOCD debug stub..

This is what I see in the log:

<  16> send packet: $qfThreadInfo#bb
<   5> read packet: $l#6c

And here's code that generates it: https://github.com/gnu-mcu-eclipse/openocd/blob/b21ab1d683aaee501d45fe8a509a2043123f16fd/src/rtos/rtos.c#L370

Sep 15 2017, 4:08 PM · Restricted Project
vadimcn created D37934: Fix compatibility with OpenOCD debug stub..
Sep 15 2017, 2:47 PM · Restricted Project

Jul 5 2017

vadimcn committed rL307207: Fix libcall expansion creating DAG nodes with invalid type post type….
Fix libcall expansion creating DAG nodes with invalid type post type…
Jul 5 2017, 3:02 PM
vadimcn closed D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands. by committing rL307207: Fix libcall expansion creating DAG nodes with invalid type post type….
Jul 5 2017, 3:02 PM

Jul 1 2017

vadimcn accepted D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands..

Eli, I can commit this if you are busy. Just give a nod.

Jul 1 2017, 11:00 AM

Jun 30 2017

vadimcn accepted D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands..

Tested Eli's version and was able to build all of rustc's standard library for the wasm32-... target.

Jun 30 2017, 12:02 AM

Jun 22 2017

vadimcn added inline comments to D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands..
Jun 22 2017, 12:14 AM

Jun 16 2017

vadimcn added inline comments to D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands..
Jun 16 2017, 11:03 AM

Jun 15 2017

vadimcn added a comment to D34240: [WebAssembly] Expansion of llvm.umul.overflow with i64 type operands..

I'm definitely not an expert on this part of LLVM, but to me this change seems very fragile, as it assumes things about the types of certain DAG nodes, which may be true now, but may change in the future.

Jun 15 2017, 10:13 AM

Jun 6 2017

vadimcn committed rL304832: Use exact equality for category language matching, for all languages, except….
Use exact equality for category language matching, for all languages, except…
Jun 6 2017, 1:40 PM
vadimcn updated the diff for D33855: Fix type category matching to source language..

Rust and Go are not the only missing languages. Looks like all of the newly-added DWARF5 language codes are not covered here.

Jun 6 2017, 11:16 AM · Restricted Project

Jun 2 2017

vadimcn edited reviewers for D33855: Fix type category matching to source language., added: jingham; removed: granata.enrico.
Jun 2 2017, 11:09 PM · Restricted Project
vadimcn added reviewers for D33855: Fix type category matching to source language.: granata.enrico, zturner.
Jun 2 2017, 4:23 PM · Restricted Project
vadimcn added a comment to D33855: Fix type category matching to source language..

Though... wouldn't "category_lang == valobj_lang" be a sane default behavior for any languages not mentioned specifically below?

Jun 2 2017, 4:20 PM · Restricted Project
vadimcn created D33855: Fix type category matching to source language..
Jun 2 2017, 4:16 PM · Restricted Project

Jan 27 2017

vadimcn committed rL293373: This addresses LLDB bug 31699, which was caused by LLVM using static linking on….
This addresses LLDB bug 31699, which was caused by LLVM using static linking on…
Jan 27 2017, 11:51 PM
vadimcn closed D29146: Link LLVM dynamically on Windows, deploy Universal CRT dlls. by committing rL293373: This addresses LLDB bug 31699, which was caused by LLVM using static linking on….
Jan 27 2017, 11:51 PM · Restricted Project
vadimcn committed rL293349: Test commit..
Test commit.
Jan 27 2017, 4:10 PM

Jan 26 2017

vadimcn added a comment to D29146: Link LLVM dynamically on Windows, deploy Universal CRT dlls..

Could we make CMAKE_INSTALL_UCRT_LIBRARIES the default when building for Windows? Would there be any downside to that?

Jan 26 2017, 1:41 PM · Restricted Project

Jan 25 2017

vadimcn updated subscribers of D29146: Link LLVM dynamically on Windows, deploy Universal CRT dlls..
Jan 25 2017, 1:53 PM · Restricted Project
vadimcn created D29146: Link LLVM dynamically on Windows, deploy Universal CRT dlls..
Jan 25 2017, 1:41 PM · Restricted Project

Dec 21 2016

vadimcn added a comment to D27476: Install lldb Python module on Windows..

Ping! Should I ask somebody else to review?

Dec 21 2016, 8:30 PM · Restricted Project

Dec 6 2016

vadimcn retitled D27476: Install lldb Python module on Windows. from to Install lldb Python module on Windows..
Dec 6 2016, 11:52 AM · Restricted Project

Nov 2 2015

vadimcn added a comment to D14044: Support for 32-bit mingw-w64 in compiler-rt..

@rnk Can you please commit it? Thanks!

Nov 2 2015, 5:57 PM

Nov 1 2015

vadimcn updated the diff for D14044: Support for 32-bit mingw-w64 in compiler-rt..

@rnk, Sounds like compiler-rt *is* a drop-in replacement for libgcc, so let's add 64-bit versions of chkstk/alloca for gcc objects.

Nov 1 2015, 5:44 PM

Oct 26 2015

vadimcn added a comment to D14044: Support for 32-bit mingw-w64 in compiler-rt..
In D14044#275303, @rnk wrote:

Here's how I understand the various functions:

  • __chkstk from msvcrt: takes size in RAX, probes all pages, returns preserving all registers.
  • __chkstk_ms from mingw: copies __chkstk from msvcrt
  • _alloca / __chkstk from mingw: helpers for implementing C alloca() with custom conventions. They trash volatile registers (ECX/RCX), update the SP, and return a new object address in RAX.
Oct 26 2015, 11:05 AM

Oct 25 2015

vadimcn updated the diff for D14044: Support for 32-bit mingw-w64 in compiler-rt..

Sorry, one more revision. Apparently chkstk needs triple underscore... <sigh>

Oct 25 2015, 11:30 PM
vadimcn updated the diff for D14044: Support for 32-bit mingw-w64 in compiler-rt..

On second thought, elimination of probe for the last page is not correct - that final push of the return address could land on the next page...
Also, I've figured out a better way to preserve eax.

Oct 25 2015, 4:20 PM

Oct 24 2015

vadimcn updated the diff for D14044: Support for 32-bit mingw-w64 in compiler-rt..

After playing with this some more - it's no fun linking with gcc-generated libraries, because they actually do use __checkstk_ms, so you have to pull in libgcc as well, and end up with duplicate symbols. Let's add _chkstk as an extra, not as replacement.

Oct 24 2015, 10:14 PM
vadimcn retitled D14044: Support for 32-bit mingw-w64 in compiler-rt. from to Support for 32-bit mingw-w64 in compiler-rt.
Oct 24 2015, 5:26 PM

Oct 22 2015

vadimcn added a comment to D11085: compiler-rt: add support for mingw-w64 in builtins.

Hi!
So apparently LLVM lowers alloca's of large buffers into a call to _alloca (makes sense I guess - if the buffer is larger than a page).
Why wasn't it added along with _chkstk? Is _alloca available from some other mingw library?

Oct 22 2015, 11:47 PM

Dec 9 2014

vadimcn updated the diff for D6547: [compiler-rt] Upstreaming small changes from the Rust project..

Dropped "-fPIC" part of the change, dropped #ifdef WIN32_ check.

Dec 9 2014, 2:22 AM
vadimcn added inline comments to D6547: [compiler-rt] Upstreaming small changes from the Rust project..
Dec 9 2014, 2:20 AM

Dec 6 2014

vadimcn added reviewers for D6547: [compiler-rt] Upstreaming small changes from the Rust project.: abdulras, joerg.

Hi,
You guys seem to be the most active in compiler-rt repo. Can you please review and commit? (or suggest somebody more appropriate). Thanks!

Dec 6 2014, 1:32 PM

Dec 4 2014

vadimcn updated D6547: [compiler-rt] Upstreaming small changes from the Rust project..
Dec 4 2014, 7:25 PM
vadimcn retitled D6547: [compiler-rt] Upstreaming small changes from the Rust project. from to [compiler-rt] Upstreaming small changes from the Rust project..
Dec 4 2014, 7:19 PM
vadimcn resigned from D4052: [PATCH] Fix for http://llvm.org/bugs/show_bug.cgi?id=19905.
Dec 4 2014, 5:58 PM
vadimcn closed D4334: Fix .seh_stackalloc 0.

This was committed by @rnk in r212081.

Dec 4 2014, 5:57 PM

Aug 1 2014

vadimcn updated the diff for D4751: Fix failure to invoke exception handler on Win64..

Implemented 'SEH_Epilogue' approach.

Aug 1 2014, 5:11 PM
vadimcn added inline comments to D4751: Fix failure to invoke exception handler on Win64..
Aug 1 2014, 11:39 AM
vadimcn updated the diff for D4751: Fix failure to invoke exception handler on Win64..
Aug 1 2014, 2:48 AM
vadimcn retitled D4751: Fix failure to invoke exception handler on Win64. from to Fix failure to invoke exception handler on Win64..
Aug 1 2014, 1:39 AM

Jun 30 2014

vadimcn added a reviewer for D4334: Fix .seh_stackalloc 0: rnk.
Jun 30 2014, 12:57 PM

Jun 27 2014

vadimcn retitled D4334: Fix .seh_stackalloc 0 from to Fix .seh_stackalloc 0.
Jun 27 2014, 8:13 PM

Jun 23 2014

vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.

@chapuni, Which tests broke? Is there a PR?
I saw that MultiJitTest.JitPool fails, but it was failing before my change too, so I ignored it.

Jun 23 2014, 2:44 PM
vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.

Hmm, something must be wrong at the MC layer. When I assemble the output of llc with gnu assembler (after replacing register numbers with names in seh directives), it seems to produce a correct .obj.

Jun 23 2014, 1:23 AM

Jun 22 2014

vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.
In D4081#42, @Twobit wrote:

Looks like something wrong with .pdata segment. It contains Function start address == Function end address and not always sorted by start address.

Jun 22 2014, 10:31 PM

Jun 20 2014

vadimcn added a comment to D4196: Replace the Execution Engine's mutex with std::recursive_mutex.

FYI - this commit broke LLVM build using win32 threads flavor of the mingw toolchain. I am getting error: 'recursive_mutex' in namespace 'std' does not name a type.
Not sure if this would be considered a problem for LLVM...

Jun 20 2014, 12:07 AM

Jun 19 2014

vadimcn updated the diff for D4081: Generate SEH unwinding info on Win64.

Fixed x86-64-static-relo-movl.ll and rebased.

Jun 19 2014, 6:26 PM
vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.

Is 'x86_64-pc-win32-macho' a valid target? Windows 64 ABI in OSX object file seems like a weird combination.

Jun 19 2014, 4:49 PM

Jun 18 2014

vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.

Yes, please commit, if you don't mind running format yourself.

Jun 18 2014, 3:15 PM
vadimcn added inline comments to D4081: Generate SEH unwinding info on Win64.
Jun 18 2014, 1:39 PM
vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.

@rnk, ping...

Jun 18 2014, 12:16 AM

Jun 13 2014

vadimcn updated the diff for D4081: Generate SEH unwinding info on Win64.

Addressed review comments.

Jun 13 2014, 6:28 PM
vadimcn added inline comments to D4081: Generate SEH unwinding info on Win64.
Jun 13 2014, 6:18 PM

Jun 12 2014

vadimcn added a comment to D4081: Generate SEH unwinding info on Win64.
In D4081#16, @loladiro wrote:

I went and tried this out but ran into an assertion. This is odd because at that stage I wasn't actually using COFF, but rather ELF in memory for MCJIT. Maybe there's a check missing whether we are using COFF in addition to Win64? See below:

Program: C:\mingw-builds\msys64\home\kfischer\julia\usr\bin\julia.exe
File: C:/mingw-builds/msys64/home/kfischer/julia/deps/llvm-svn/lib/CodeGen/MachineInstr.cpp, Line 674

Expression: (isImpReg || Op.isRegMask() || MCID->isVariadic() || OpNo < MCID->getNumOperands() || isMetaDataOp) && "Trying to add an operand to a machine instr that is already done!"
Jun 12 2014, 2:13 PM

Jun 10 2014

vadimcn added inline comments to D4081: Generate SEH unwinding info on Win64.
Jun 10 2014, 12:42 PM
vadimcn updated the diff for D4081: Generate SEH unwinding info on Win64.
Jun 10 2014, 8:29 AM
vadimcn updated the diff for D4081: Generate SEH unwinding info on Win64.

Whoops, looks like I got .cfi_offset and .cfi_rel_offset mixed up. The original offsets in bigstructret2.ll test were actually correct.
Also, rebased on top of master.

Jun 10 2014, 8:06 AM

Jun 9 2014

vadimcn abandoned D4053: Win64 SEH preliminary patch.

Superceded by D4081

Jun 9 2014, 9:40 PM
vadimcn added a comment to D3418: SEH exceptions on Win64 (LLVM).

I ended up with an almost complete rewrite, so positing it as a new review: D4081

Jun 9 2014, 9:38 PM
vadimcn added reviewers for D4081: Generate SEH unwinding info on Win64: nrieck, rnk, asl, chapuni.
Jun 9 2014, 9:34 PM
vadimcn retitled D4081: Generate SEH unwinding info on Win64 from to Generate SEH unwinding info on Win64.
Jun 9 2014, 9:27 PM
vadimcn added a comment to D4052: [PATCH] Fix for http://llvm.org/bugs/show_bug.cgi?id=19905.

I've updated my patch. It should now solve your problem too.

Jun 9 2014, 6:50 PM
vadimcn updated the diff for D4053: Win64 SEH preliminary patch.
Jun 9 2014, 2:20 AM

Jun 8 2014

vadimcn added a comment to D4052: [PATCH] Fix for http://llvm.org/bugs/show_bug.cgi?id=19905.

@sanjoy, I wonder what happens with your patch in case of stack re-alignment.
Sorry, I can't figure out how to get git to apply your diff. Could you please try it on the following IR:

Jun 8 2014, 12:54 AM

Jun 7 2014

vadimcn added a comment to D4052: [PATCH] Fix for http://llvm.org/bugs/show_bug.cgi?id=19905.

Looking at the llc output you provided in the bug, I notice that it spilled and emitted CFI info for XMM registers. What target was that compiled for? AFAIK, only Windows 64 ABI specifies XMMs as callee-saved. So if it was for Win64, my patch would directly address your problem.

Jun 7 2014, 3:15 PM

Jun 6 2014

vadimcn updated the diff for D4053: Win64 SEH preliminary patch.

With more context

Jun 6 2014, 7:16 PM
vadimcn added a comment to D4052: [PATCH] Fix for http://llvm.org/bugs/show_bug.cgi?id=19905.

Hi Sanjay,
Please take a look at my preliminary patch to support Win64 SEH I've put here: http://reviews.llvm.org/D4053 (specifically stuff in X86FrameLowering.cpp). Not directly related to 19905, however, it touches the same code, and could benefit from the same refactoring.

Jun 6 2014, 7:06 PM
vadimcn retitled D4053: Win64 SEH preliminary patch from to Win64 SEH preliminary patch.
Jun 6 2014, 6:40 PM

May 2 2014

vadimcn added a comment to D3422: Win64 SEH print register names.

This patch doesn't work right. I am seeing stuff like this in the emitted code:

	pushq	%rbp
	.seh_pushreg %rdi

Which, I guess, makes sense, because MCAsmStreamer::EmitRegisterName performs DWARF->LLVM register index mapping before emitting the name.

May 2 2014, 5:24 PM

Apr 28 2014

vadimcn added a comment to D3418: SEH exceptions on Win64 (LLVM).

@nrieck, you've said above "I believe it's not necessary to change the prologue emission for Win64". However I don't see how would one express 'and ..., %rsp' with SEH unwind instructions, because the effective RSP offset here is not a compile-time constant.

Apr 28 2014, 6:23 PM

Apr 25 2014

vadimcn added a comment to D3418: SEH exceptions on Win64 (LLVM).

There's been much back-and-forth on the mailing list thread, so I am no longer sure which problems absolutely need to be fixed, and which were mentioned just in passing. It would be helpful to restate them in one place (here probably).

Apr 25 2014, 3:33 PM
vadimcn added a comment to D3418: SEH exceptions on Win64 (LLVM).

Ping... It's been a week since anything happened on this review. Is there any action that can be taken to un-stall this?

Apr 25 2014, 2:00 PM