zturner (Zachary Turner)
User

Projects

User does not belong to any projects.

User Details

User Since
May 26 2014, 12:49 PM (220 w, 6 d)

Recent Activity

Yesterday

zturner committed rL340126: [MS Demangler] Resolve backreferences eagerly, not lazily..
[MS Demangler] Resolve backreferences eagerly, not lazily.
Sat, Aug 18, 11:50 AM

Fri, Aug 17

zturner committed rL340118: Add the extended XMM registers mappings for AVX-512..
Add the extended XMM registers mappings for AVX-512.
Fri, Aug 17, 8:55 PM
zturner added a comment to D50807: [Error] Add FileError and DebugErrorInfo helpers.

Is it possible for

Fri, Aug 17, 3:02 PM
zturner committed rL340088: [MS Demangler] Properly print all thunk types..
[MS Demangler] Properly print all thunk types.
Fri, Aug 17, 2:32 PM
zturner committed rL340083: [MS Demangler] Demangle all remaining types of operators..
[MS Demangler] Demangle all remaining types of operators.
Fri, Aug 17, 2:18 PM
zturner committed rL340046: [MS Demangler] Rework the way operators are demangled..
[MS Demangler] Rework the way operators are demangled.
Fri, Aug 17, 9:14 AM
zturner added inline comments to D50839: [llvm] Optimize YAML::isNumeric.
Fri, Aug 17, 7:47 AM
zturner updated subscribers of D50839: [llvm] Optimize YAML::isNumeric.

I suspected something would be wrong with that approach, it would be too
simple otherwise :) lgtm

Fri, Aug 17, 7:26 AM

Thu, Aug 16

zturner updated subscribers of D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

Can’t we just use a base class with pure virtual methods, pass it to the
demangle function, implement this in clang, and pass null from libcxxabi?
Moving the whole thing to a header file seems kinda unfortunate.

Thu, Aug 16, 6:55 PM
zturner added a comment to D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

But do you actually need those changes that pavel is working on? That looks
like a whole bunch of code that someone who just wants to print a demangled
name won’t care about. How involved are bugs usually, because I’m imagining
they’re a) usually just a couple lines change and b) pretty infrequent.
Once the relicense happens, you just change the include path and include
the real one.

Thu, Aug 16, 6:04 PM
zturner updated subscribers of D50877: [MS] Mangle a hash of the main file path into anonymous namespaces.

IIRC it’s ?A0xABCDABCD@ where the hex value is some kind of hash

Thu, Aug 16, 5:37 PM
zturner updated subscribers of D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

Another option is to simply move it into support and say that going forward
merges to libcxxabi might get more difficult. Perhaps this isn’t so bad
though. Isn’t the itanium demangler mostly complete? If the potential for
future changes to it is low, maybe this is an acceptable tradeoff. Then we
could just move it to support, use it and evolve it any way we want with no
restrictions, and when new functionality gets added to the itanium mangler
that needs to be port to libcxxabi, it’s a little more effort than a simple
copy paste because you have to think about it some.

Thu, Aug 16, 5:33 PM
zturner added a comment to D50875: Move lib/Demangle under lib/Support. No functionality change intended..

If the licensing issue is that libc++abi can't include code from Support, then it also can't include Compiler.h. So I feel like this code move is just a bandaid instead of a proper solution. Can we use dependency injection or something to get some hooks into the demangler that allow you to customize the behavior from Clang / LLVM, as described in D50828?

Thu, Aug 16, 4:16 PM
zturner added a comment to D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

If we're not going to allow code from Support to be used in the demangler, then I don't think we should move it to support, because it will be too easy for people to mess up and use code they shouldn't.

Thu, Aug 16, 4:13 PM
zturner added a comment to D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

I think the only reasonable way to handle this is for Demangle to move into Support. We could keep the headers separate but move the implementation into lib/Support/Demangle, similar to what we do for AST. Or we could also move the headers to include/llvm/Support/Demangle. My preference is the latter; it seems reasonable to me for Demangle to generally live inside Support.

Sure, I really don't know why we didn't just do that to start with. The original RFC[1] talked about putting the demangler into Support, but the commit that materialized it (r280732) put Demangle into it's own library. Would be nice to get @zturner's sign-off for a move too, since he owns the microsoft demangler.

[1]: https://groups.google.com/forum/#!topic/llvm-dev/v_7OuWx8n1A

My understanding is that Demangle is used by other projects like compiler-rt which can't depend on Support. If I'm wrong, it would be great. For some reason I can't find it when I search the archive, but if you search your inbox for "llvm r328123" you'll find a long discussion thread with various people who were dealing with this and/or may know something about it. Anyway, I'm CC'ing them all here.

Personally if we can get Demangle into support I would be very happy.

That's why all of this is behind an #ifdef? It seems to be trying to preserve the ability to build a stand-alone demangler that does not in fact pull in Support or anything else.

The question is, who needs that? Can we just put it *into* Support?

libc++abi is under a different license than support.

We can't fix this until at a minimum the relicensing is "done".

Thu, Aug 16, 4:04 PM
zturner added a comment to D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended..

I think the only reasonable way to handle this is for Demangle to move into Support. We could keep the headers separate but move the implementation into lib/Support/Demangle, similar to what we do for AST. Or we could also move the headers to include/llvm/Support/Demangle. My preference is the latter; it seems reasonable to me for Demangle to generally live inside Support.

Sure, I really don't know why we didn't just do that to start with. The original RFC[1] talked about putting the demangler into Support, but the commit that materialized it (r280732) put Demangle into it's own library. Would be nice to get @zturner's sign-off for a move too, since he owns the microsoft demangler.

[1]: https://groups.google.com/forum/#!topic/llvm-dev/v_7OuWx8n1A

My understanding is that Demangle is used by other projects like compiler-rt which can't depend on Support. If I'm wrong, it would be great. For some reason I can't find it when I search the archive, but if you search your inbox for "llvm r328123" you'll find a long discussion thread with various people who were dealing with this and/or may know something about it. Anyway, I'm CC'ing them all here.

Personally if we can get Demangle into support I would be very happy.

That's why all of this is behind an #ifdef? It seems to be trying to preserve the ability to build a stand-alone demangler that does not in fact pull in Support or anything else.

Thu, Aug 16, 3:59 PM
zturner added reviewers for D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended.: bogner, chandlerc, dblaikie.

I think the only reasonable way to handle this is for Demangle to move into Support. We could keep the headers separate but move the implementation into lib/Support/Demangle, similar to what we do for AST. Or we could also move the headers to include/llvm/Support/Demangle. My preference is the latter; it seems reasonable to me for Demangle to generally live inside Support.

Sure, I really don't know why we didn't just do that to start with. The original RFC[1] talked about putting the demangler into Support, but the commit that materialized it (r280732) put Demangle into it's own library. Would be nice to get @zturner's sign-off for a move too, since he owns the microsoft demangler.

[1]: https://groups.google.com/forum/#!topic/llvm-dev/v_7OuWx8n1A

Thu, Aug 16, 3:56 PM
zturner committed rL339909: Fix memory leak in demangling of string literals..
Fix memory leak in demangling of string literals.
Thu, Aug 16, 10:49 AM
zturner accepted D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

Thanks for being patient. Looking forward to actually using this on my Linux box.

Thu, Aug 16, 10:42 AM
zturner added inline comments to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.
Thu, Aug 16, 10:36 AM
zturner accepted D50851: [codeview] Use push_macro to avoid conflicts instead of a prefix.
Thu, Aug 16, 10:31 AM
zturner added inline comments to D50839: [llvm] Optimize YAML::isNumeric.
Thu, Aug 16, 10:24 AM
zturner added inline comments to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.
Thu, Aug 16, 10:06 AM
zturner committed rL339894: Fix -Wmicrosoft-goto warnings..
Fix -Wmicrosoft-goto warnings.
Thu, Aug 16, 9:31 AM
zturner added a comment to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

I had a couple of other comments, but since I responded from email since I was on the go and I guess they didn't show up inline. Sorry about that. If you prefer I can resubmit them all as inline comments, or I guess you can just respond to the email thread.

Thu, Aug 16, 9:23 AM
zturner committed rL339893: Add support for AVX-512 CodeView registers..
Add support for AVX-512 CodeView registers.
Thu, Aug 16, 9:18 AM
zturner closed D50819: Add support for AVX-512 CodeView Registers.
Thu, Aug 16, 9:18 AM
zturner committed rL339892: [MS Demangler] Demangle string literals..
[MS Demangler] Demangle string literals.
Thu, Aug 16, 9:18 AM
zturner closed D50806: [MS Demangler] Demangle string literals.
Thu, Aug 16, 9:18 AM
zturner committed rL339891: [MS Demangler] Don't fail on MD5-mangled names..
[MS Demangler] Don't fail on MD5-mangled names.
Thu, Aug 16, 9:18 AM

Wed, Aug 15

zturner added a comment to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

Looking pretty good, I went over it again and found a few more things. There's a bit more auto than I'm comfortable with, but I'm not gonna make a big deal about it. it does make the code a bit hard to read when it's used for trivial return values though.

Wed, Aug 15, 8:16 PM
zturner created D50819: Add support for AVX-512 CodeView Registers.
Wed, Aug 15, 4:23 PM
zturner added inline comments to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.
Wed, Aug 15, 3:12 PM
zturner created D50806: [MS Demangler] Demangle string literals.
Wed, Aug 15, 1:45 PM
zturner updated subscribers of D50789: [TableGen] Remove unnecessary TypeSetByHwMode -> ValueTypeByHwMode -> TypeSetByHwMode conversions in getPatternSize.

This looks great. I've tried to reduce the MSVC debug build time as well,
but I didn't find this particular problem. I can't comment on the
correctness since I don't know much about how tablegen is implemented, but
I just wanted to say that this kind of thing is very appreciated and I hope
you continue doing more of it :)

Wed, Aug 15, 10:24 AM
zturner added inline comments to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.
Wed, Aug 15, 9:34 AM

Tue, Aug 14

zturner committed rL339708: [MS Demangler] Fix some minor formatting bugs..
[MS Demangler] Fix some minor formatting bugs.
Tue, Aug 14, 11:55 AM
zturner added a comment to D50564: Add support for SEH unwinding on Windows..
In D50564#1199285, @rnk wrote:

Could somebody verify that the DISPATCHER_CONTEXT struct is defined in <winnt.h> for the Win8 and Win10 SDKs? I can't install them right now.

I checked both, and they are available, so I think we should guard the definition like this:

// Provide a definition for _DISPATCHER_CONTEXT for Win7 and earlier SDK versions.
// Mingw64 has always provided this struct.
#if defined(_LIBUNWIND_SUPPORT_SEH_UNWIND) && !defined(__MINGW64__) && defined(WINVER) && WINVER < _WIN32_WINNT_WIN8
# if defined(__x86_64__)
typedef struct _DISPATCHER_CONTEXT { ... } DISPATCHER_CONTEXT;
# elif defined(__arm__)
typedef struct _DISPATCHER_CONTEXT { ... } DISPATCHER_CONTEXT;
# endif
#endif

Does that seem right? I'm not super familiar with SDK version detection, so I might have the wrong macros.

Tue, Aug 14, 10:12 AM

Mon, Aug 13

zturner added a comment to D50664: [LLD] Normalize PDB error messages.

I would split this into 3 separate patches.

Mon, Aug 13, 2:56 PM
zturner accepted D49980: [PDB] Parse UDT symbols and pointers to members (combined patch).
Mon, Aug 13, 2:41 PM
zturner accepted D50299: Migrate to std::function instead of static member functions for callbacks.

Sorry for the delay, was on vacation last week.

Mon, Aug 13, 2:39 PM
zturner accepted D50521: [Support] NFC: Allow modifying access/modification times independently in sys::fs::setLastModificationAndAccessTime..
Mon, Aug 13, 2:37 PM
zturner added a comment to D49980: [PDB] Parse UDT symbols and pointers to members (combined patch).

Ok I’ll take a look later today then when i get in

Mon, Aug 13, 7:38 AM

Fri, Aug 10

zturner committed rL339471: [MS Demangler] Support extern "C" functions..
[MS Demangler] Support extern "C" functions.
Fri, Aug 10, 2:09 PM
zturner committed rL339466: Resubmit r339450 - [MS Demangler] Add conversion operator tests.
Resubmit r339450 - [MS Demangler] Add conversion operator tests
Fri, Aug 10, 1:09 PM
zturner committed rL339465: [MS Demangler] Demangle cv qualifiers on template args..
[MS Demangler] Demangle cv qualifiers on template args.
Fri, Aug 10, 12:58 PM
zturner committed rL339450: [MS Demangler] Add conversion operator tests..
[MS Demangler] Add conversion operator tests.
Fri, Aug 10, 9:56 AM
zturner committed rL339436: [MS Demangler] Properly demangle conversion operators..
[MS Demangler] Properly demangle conversion operators.
Fri, Aug 10, 8:05 AM
zturner committed rL339435: [MS Demangler] Disable a couple of tests..
[MS Demangler] Disable a couple of tests.
Fri, Aug 10, 7:54 AM
zturner committed rL339434: [MS Demangler] Fix several issues related to templates..
[MS Demangler] Fix several issues related to templates.
Fri, Aug 10, 7:31 AM
zturner closed D50512: [MS Demangler] Fix several issues related to templates.
Fri, Aug 10, 7:31 AM

Thu, Aug 9

zturner created D50512: [MS Demangler] Fix several issues related to templates.
Thu, Aug 9, 7:30 AM

Wed, Aug 8

zturner committed rL339275: [MS Demangler] Create a new backref context for template instantiations..
[MS Demangler] Create a new backref context for template instantiations.
Wed, Aug 8, 10:17 AM
zturner accepted D50384: Move Predicate.h from Host to Utility.

lgtm, although Predicate is simple enough that I wonder if one day we should try to just delete it entirely.

Wed, Aug 8, 8:33 AM
zturner added a comment to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

To elaborate, if you install the C/C++ plugin, and you go to Debug ->
Configurations, and you go down to the MICmdMode property, it is by default
set to "gdb". But you can change this to "lldb" and it works out of the
box.

Wed, Aug 8, 8:32 AM
zturner added a comment to D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol.

How does this differ from VS Code's builtin LLDB MI support?

Wed, Aug 8, 8:30 AM

Tue, Aug 7

zturner committed rL339211: [MS Demangler] Properly handle backreferencing of special names..
[MS Demangler] Properly handle backreferencing of special names.
Tue, Aug 7, 5:44 PM
zturner closed D50394: [MS Demangler] Properly handle backreferences of special names.
Tue, Aug 7, 5:44 PM
zturner added a comment to D50397: [lit, python3] Update lit error logging to work correctly in python3 and other test fixes.

No that’s fine, only makes sense to use it if it fits naturally. As long as
you tried. Lgtm as is

Tue, Aug 7, 11:53 AM
zturner updated subscribers of D50397: [lit, python3] Update lit error logging to work correctly in python3 and other test fixes.

We have a function somewhere in lit utils that does this, but I’m OOO so I
can’t look for it. Can you try to find it?

Tue, Aug 7, 11:06 AM
zturner updated subscribers of D50398: Update msbuild integration warnings: Don't warn on /Zi and /X.

Lgtm

Tue, Aug 7, 11:04 AM
zturner created D50394: [MS Demangler] Properly handle backreferences of special names.
Tue, Aug 7, 9:36 AM

Mon, Aug 6

zturner updated subscribers of D50258: [llvm-pdbutil] Support PDBs without a DBI stream.

Ok 60kb is probably fine. Lgtm

Mon, Aug 6, 8:38 AM
zturner added a comment to D50335: vs integration: fix default path to clang-cl.

If you go to vs settings you can go to project -> build & run -> output
level and set it to Diagnostic. Then Ctrl+F for LLVMInstallDir and you
should see the value. Try this with @ and with \ and see if they’re
different.

Mon, Aug 6, 8:29 AM
zturner added a comment to D50335: vs integration: fix default path to clang-cl.

In that case I think the first version was correct. LLVM@LLVM means “the
value LLVM under the key LLVM”. LLVM\LLVM means “the default value under
the key LLVM which itself is under the key LLVM”

Mon, Aug 6, 8:22 AM
zturner updated subscribers of D50336: Add support for ARM and ARM64 breakpad generated minidump files (version 2)..

Did you see my comments on the first round about how the CMake build didn’t
work? Because I don’t see any changes to CMakeLists.txt here, which means
it still won’t work.

Mon, Aug 6, 8:19 AM
zturner added a comment to D50335: vs integration: fix default path to clang-cl.

I’m OOO this week so I can’t easily check this stuff. Sorry for all the
questions. The registry key that we create, is it the (Default) value or is
it a string value named LLVM?

Mon, Aug 6, 8:11 AM
zturner updated subscribers of D49980: [PDB] Parse UDT symbols and pointers to members (combined patch).

I am OOO this week and only have access to mobile, so hopefully someone
else can review it

Mon, Aug 6, 8:08 AM
zturner added a comment to D50335: vs integration: fix default path to clang-cl.

I’m pretty sure I tested this code path, was it wrong? Also I don’t think
we should be explicitly adding the \ after the $(LLVMInstallDir), if you
look through the way every other path in a VS project works, they assume
the \ is in the registry path, so if it’s possible I think we should follow
the same pattern.

Mon, Aug 6, 7:55 AM

Sun, Aug 5

zturner updated subscribers of D50299: Migrate to std::function instead of static member functions for callbacks.

std::function might be able to construct itself efficiently from a lambda,
but once it’s in the std::function all that info is lost and moving it
around more will always copy (unless you explicitly move). We only really
assign it once, so this isn’t an issue, but unique_function is nice from a
purist point of view in that it won’t ever allow std::function’s slow path
to be taken, even accidentally.

Sun, Aug 5, 4:26 PM

Sat, Aug 4

zturner added inline comments to D50299: Migrate to std::function instead of static member functions for callbacks.
Sat, Aug 4, 4:01 PM

Fri, Aug 3

zturner added a comment to D50290: Fix a bug in VMRange.

Looks like i was wrong, nevermind!

Fri, Aug 3, 6:37 PM · Restricted Project
zturner updated subscribers of D50290: Fix a bug in VMRange.

I think we have llvm::contains() which would allow you to make this
slightly better. Other than that, good find!

Fri, Aug 3, 5:58 PM · Restricted Project
zturner accepted D50206: [lit, python] Always add quotes around the python path in lit.
Fri, Aug 3, 4:05 PM
zturner added a comment to D49740: Move RegisterValue,Scalar,State from Core to Utility.

For the Register stuff, for example, I think it could make sense for it to be in a project such as HAL (Hardware Abstraction Layer) or something similarly named. Everything that describes properties of specific CPUs could go there, perhaps even including ArchSpec. For the Scalar stuff, perhaps a target called Visualization (or even just Value). Once more and more stuff starts ending up in Utility, I think it makes sense to try something like this.

Fri, Aug 3, 2:59 PM
zturner added a comment to D49740: Move RegisterValue,Scalar,State from Core to Utility.

Several months ago when this came up, i hypothesized that Utility would
eventually contain a mix of random stuff some of which may not make sense
in the long term. But that in the meantime, it’s useful to have some sort
of layering abstraction for “has no other dependencies”. Eventually when
this reaches critical mass, a natural separation should present itself,
because all the stuff that conceptually belongs together will be in
Utility. So then we can break Utility up into a more logical separation

Fri, Aug 3, 12:53 PM
zturner added inline comments to D50258: [llvm-pdbutil] Support PDBs without a DBI stream.
Fri, Aug 3, 11:24 AM
zturner updated subscribers of D49740: Move RegisterValue,Scalar,State from Core to Utility.

No objections here

Fri, Aug 3, 8:36 AM

Thu, Aug 2

zturner updated subscribers of D50206: [lit, python] Always add quotes around the python path in lit.

Should the substitution just be surrounded by quotes automatically so we
don’t have this problem?

Thu, Aug 2, 4:25 PM
zturner committed rL338778: [MS Demangler] Fix some tests that are no longer broken..
[MS Demangler] Fix some tests that are no longer broken.
Thu, Aug 2, 3:38 PM
zturner accepted D50198: [lldbsuite, windows] Mark tests as XFAIL on Windows or skip them.
Thu, Aug 2, 1:06 PM
zturner committed rLLDB338746: Fix CMake build..
Fix CMake build.
Thu, Aug 2, 10:45 AM
zturner committed rL338746: Fix CMake build..
Fix CMake build.
Thu, Aug 2, 10:45 AM
zturner added a comment to D49750: Add support for ARM and ARM64 breakpad generated minidump files..

Please remember to test with the cmake build when you add or remove files,
as that is the build that all of the buildbots use. I almost reverted this
since it broke every LLDB buildbot, but I noticed that it's just forgetting
to remove the files from the CMakeLists.txt so I'll fix it.

Thu, Aug 2, 10:41 AM
zturner accepted D50126: [Support] fix TempFile infinite loop and permission denied errors.
Thu, Aug 2, 10:36 AM
zturner committed rL338742: Fix one more warning..
Fix one more warning.
Thu, Aug 2, 10:34 AM
zturner committed rL338740: Update the LLVM VS integration to sign the assembly..
Update the LLVM VS integration to sign the assembly.
Thu, Aug 2, 10:21 AM
zturner committed rL338739: Fix a couple of warnings..
Fix a couple of warnings.
Thu, Aug 2, 10:18 AM
zturner committed rL338737: Use %.*s instead of %*s when formatting strings with explicit length..
Use %.*s instead of %*s when formatting strings with explicit length.
Thu, Aug 2, 10:08 AM
zturner committed rL338736: [MS Demangler] Resolve back-references lazily..
[MS Demangler] Resolve back-references lazily.
Thu, Aug 2, 10:08 AM

Wed, Aug 1

zturner committed rL338614: Try to fix FreeBSD build..
Try to fix FreeBSD build.
Wed, Aug 1, 11:44 AM
zturner committed rL338609: [llvm-undname Add an option to dump back references..
[llvm-undname Add an option to dump back references.
Wed, Aug 1, 11:33 AM
zturner committed rL338608: [MS Demangler] Properly demangle templated operators..
[MS Demangler] Properly demangle templated operators.
Wed, Aug 1, 11:33 AM
zturner closed D50145: [MS Demangler] Demangle templated operator overloads.
Wed, Aug 1, 11:33 AM
zturner committed rL338607: [MS Demangler] Don't crash as often when demangling..
[MS Demangler] Don't crash as often when demangling.
Wed, Aug 1, 11:33 AM
zturner updated the diff for D50145: [MS Demangler] Demangle templated operator overloads.

Use boolean variables instead of a Flags enum.

Wed, Aug 1, 11:01 AM
zturner created D50145: [MS Demangler] Demangle templated operator overloads.
Wed, Aug 1, 9:44 AM

Tue, Jul 31

zturner updated subscribers of D50127: [Support] use larger character set for creating unique filenames.

It would be an extra line of code, but I think this would be clearer (with
even less chance of collision) if you just choose a random number in [0,35]
and map it to [0-9][a-z]. The bit twiddling and array indexing seems like
unnecessary cleverness and someone could accidentally come along and break
it if they weren’t careful.

Tue, Jul 31, 9:11 PM
zturner updated subscribers of D50126: [Support] fix TempFile infinite loop and permission denied errors.

How could 16 characters not be enough? That’s 35^16 unique file names?

Tue, Jul 31, 8:21 PM
zturner added a comment to D50048: [Windows FS] Allow moving files in TempFile::keep.
In D50048#1183101, @pcc wrote:

Can't we change dsymutil to create its temporary file in the same directory as the destination?

Tue, Jul 31, 12:04 PM