Page MenuHomePhabricator

clayborg (Greg Clayton)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 23 2014, 10:11 AM (289 w, 7 h)

Recent Activity

Yesterday

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

The biggest issue is maintaining the API. We can't add anything to SBCommandPluginInterface

If we're going to be adding a new inheritable class for this feature, I'd recommend adding about half a dozen or so dummy virtual methods to it so we reserve vtable space for future expansion.

Mon, Apr 6, 11:57 AM · Restricted Project
clayborg accepted D77295: [lldb/Core] Fix a race in the Communication class.
Mon, Apr 6, 11:57 AM · Restricted Project

Sun, Apr 5

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

I was thinking if auto repeat was enabled that the DoExecute would just get called again with nothing and then the plug-in could maintain any repeat commands without needing to add anything... Glad you chimed in!

Sun, Apr 5, 10:25 PM · Restricted Project
clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

The biggest issue is maintaining the API. We can't add anything to SBCommandPluginInterface

Sun, Apr 5, 10:25 PM · Restricted Project

Fri, Apr 3

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

LGTM. Pavel?

Fri, Apr 3, 6:26 PM · Restricted Project
clayborg added a comment to D77326: 1/2: [nfc] [lldb] Unindent code.

Does anyone know why harbormaster is useless?

Fri, Apr 3, 3:11 PM · Restricted Project
clayborg added a comment to D74169: [WIP][LLD][ELF][DebugInfo] Remove obsolete debug info..
In D74169#1960444, @avl wrote:

Not so much reason to support type units ("-fdebug-types-section/type units/.debug_types section/multiple .debug_info sections" all essentially describe the same thing). Since type units add object size overhead to reduced linked size in the face of a DWARF-agnostic/ignorant linker. If you have a DWARF aware linker, you'd probably avoid using type units so you could have smaller object files too.

It seems to me type units are useful for the current scheme. They increase the size of type reference(8 bytes vs 4 bytes) and introduce type unit header, but they avoid duplication. All references inside the object file point to the single type description - thus, object files have only one type's description instead of multiple copies. The effect of de-duplication is higher than the introduced increase.

Fri, Apr 3, 1:33 PM · debug-info, lld, Restricted Project
clayborg added a comment to D74169: [WIP][LLD][ELF][DebugInfo] Remove obsolete debug info..

Nice! Another thing I have been seeing a lot of is when functions are coalesced and many .o files have the same function that gets linked to the same location. We end up with many duplicate DWARF DIEs in the final executable since the linker will just link all of the DWARF for each function over and over (.debug_info and .debug_line content). I found this when making GSYM files from the DWARF and noticing that I had hundreds of duplicate entries that matched exactly. This would be a great follow up patch for --gc-debuginfo

Given this is built on top of the DWARFLinker used for llvm-dsymutil which, I believe, already strips out those duplicate descriptions - hopefully that's already included in the functionality under review? But good to check/ask - @avl does this patch already do the good things for duplicate (or dropped) function sections?

(eg: "inline void f1() { } void f2() { f1(); }" + "inline void f1() { } void f2(); int main() { f1(); f2(); }" compiled and linked at -O0 the DWARF would usually contain two descriptions of 'f1', but ideally with a DWARF aware linker it'd contain only one description of 'f1'. Similarly: "void f1() { } void f2() { }" + "void f2(); int main() { f2(); }" compiled and linked with -ffunction-sections -Wl,-gc-sections would normally contain a DWARF description of "f1" but no code for f1, and a DWARF aware linker would strip out the DWARF description of 'f1' here)

Fri, Apr 3, 1:33 PM · debug-info, lld, Restricted Project
clayborg added a comment to D74169: [WIP][LLD][ELF][DebugInfo] Remove obsolete debug info..

Nice! Another thing I have been seeing a lot of is when functions are coalesced and many .o files have the same function that gets linked to the same location. We end up with many duplicate DWARF DIEs in the final executable since the linker will just link all of the DWARF for each function over and over (.debug_info and .debug_line content). I found this when making GSYM files from the DWARF and noticing that I had hundreds of duplicate entries that matched exactly. This would be a great follow up patch for --gc-debuginfo

Fri, Apr 3, 12:57 PM · debug-info, lld, Restricted Project

Thu, Apr 2

clayborg committed rG5998aceda9fd: Have lldb-vscode update the currently selecte thread and frame when it receives… (authored by clayborg).
Have lldb-vscode update the currently selecte thread and frame when it receives…
Thu, Apr 2, 7:00 PM
clayborg added a comment to D77347: Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request..

commit 5998aceda9fdca04db4d9ee390cec660896bf0bf (HEAD -> master, origin/master, origin/HEAD)
Author: Greg Clayton <gclayton@fb.com>
Date: Thu Apr 2 16:30:33 2020 -0700

Thu, Apr 2, 7:00 PM · Restricted Project
clayborg closed D77347: Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request..
Thu, Apr 2, 7:00 PM · Restricted Project
clayborg updated the diff for D77347: Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request..

Fix typos.

Thu, Apr 2, 7:00 PM · Restricted Project
clayborg created D77347: Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request..
Thu, Apr 2, 4:50 PM · Restricted Project
clayborg added inline comments to D77295: [lldb/Core] Fix a race in the Communication class.
Thu, Apr 2, 3:44 PM · Restricted Project

Wed, Apr 1

clayborg updated the diff for D76964: Fix an issue where the IgnoreName function was not allowing "Class" to be looked up inside a namespace or other class..

Fixed patch reviewer suggestions and added a test for "id".

Wed, Apr 1, 4:54 PM · Restricted Project

Tue, Mar 31

clayborg added a comment to D75750: [lldb] integrate debuginfod.

Another idea for the SymbolServers: be able to specify a source repository (git, svn etc) and hash or revision ID. The symbol server can grab the source from the repo and cache is locally for display.

Tue, Mar 31, 11:25 PM · Restricted Project
clayborg accepted D77186: [source maps] Ensure all valid source maps are added instead of failing with the first invalid one.

This will do what the user intends more of the time. Good catch

Tue, Mar 31, 7:18 PM · Restricted Project
clayborg accepted D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

Just use "llvm::None" instead of "{}" and this is good to go.

Tue, Mar 31, 7:18 PM · Restricted Project
clayborg added a comment to D75750: [lldb] integrate debuginfod.

The main issue is that the symbol vendors currently are ELF, macOS and WASM. Right now we have one SymbolVendor for a triple, but I can see a SymbolVendor wanting to use multiple symbol servers to get information: one for the OS binaries (debuginfod or DebugSymbols.framework at Apple) and one for the current application with company specific symbol servers. At Apple, they can download any symbols for macOS, iOS, watchOS and tvOS OSes and applications. At Facebook we can download symbols for android, linux and iOS. Linux distros might have ways to download symbols for their OS stuff, which might work along side debuginfod? Also windows has the ability to download symbols.

Tue, Mar 31, 7:18 PM · Restricted Project

Mon, Mar 30

clayborg added a comment to D77107: [intel-pt] Implement a basic test case.

I am worried if this test will be flaky on loaded machines. Not sure how we can ever guarantee we will see processor traces with our stuff in it if the machine is busy running many tests or even doing other things.

Mon, Mar 30, 10:55 PM · Restricted Project
clayborg added a comment to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

Looks good as long as with we have "llvm::Optional<llvm::StringRef> request_path = {}" in the arguments for a function, that "{}" will turn into llvm::None and not an empty StringRef? Unclear to me. As long as this is what is happening and as long is this coding convention is used elsewhere in llvm (using "{}" instead of "llvm::None") I am ok. Pavel?

Mon, Mar 30, 10:55 PM · Restricted Project
clayborg requested changes to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

After reviewing more, we should just re-use CreateBreakpoint and add a "llvm::Optional<StringRef> request_path" argument. Then all breakpoints use the same function and we avoid duplicated code. Inline comments should detail what should be done. Let me know if you have questions.

Mon, Mar 30, 3:51 PM · Restricted Project
clayborg requested changes to D76968: [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request.

The description confused me a bit as I thought we were going to be doing some "CommandObjectSource::DumpLinesInSymbolContexts()" stuff somewhere. But this path is really just "return the same source path from the setBreakpoints" request in the response and I am all for that. So a few nits and this will be good to go. See my inline comments.

Mon, Mar 30, 1:37 PM · Restricted Project
clayborg added a comment to D75750: [lldb] integrate debuginfod.

Currently we have a solution for macOS to locate symbol files in the "lldb/source/Symbol/LocateSymbolFile.cpp" file in the Symbols::LocateExecutableSymbolFile(...) function:

static FileSpec Symbols::LocateExecutableSymbolFile(const ModuleSpec &module_spec, const FileSpecList &default_search_paths);

This will locate any files that are already on the system and return the symbol file. When you don't have a symbol file, we can call:

static bool Symbols::DownloadObjectAndSymbolFile(ModuleSpec &module_spec, bool force_lookup = true);

This might ping a build server and download the symbols.

As for source file remappings, as Jim stated, on mac, each dSYM has path remappings already inside of it that are applied on the Module (not a target wide setting) itself and no modifications need to be done to the SourceManager.

So my question is: can be use debuginfod to find the symbol file for a given build ID via Symbols::LocateExecutableSymbolFile(...), and when/if a symbol file is fetched from debuginfod, apply all path remappings to the module itself that we hand out? Then no changes would be needed in the SourceManager, we would just ask for a symbol file and get one back with all the remappings that are needed.

I've been thinking about that a lot too. The thing that's not clear to me is, does DownloadObjectAndSymbolFile download source files too? If so, how?

Mon, Mar 30, 1:37 PM · Restricted Project
clayborg added a comment to D75750: [lldb] integrate debuginfod.

I am expecting that this feature will hook in very near to DownloadObjectAndSymbolFile for downloading the debug info, but it's not clear to me how would the source files fit in. Currently, debuginfod only provides an api to retrieve a single source file, so this code would have to parse all of the debug info, pry out the source files, and download them one by one -- a complicated and slow process.

Yeah, as debuginfod does not support a batch type of source download, maybe this particular lldb site is not an ideal fit..

Mon, Mar 30, 1:37 PM · Restricted Project

Sat, Mar 28

clayborg added a comment to D76758: Augment lldb's symbol table with external symbols in Mach-O's dyld trie.

Much cleaner!

Sat, Mar 28, 5:44 PM · Restricted Project
clayborg added a comment to D75750: [lldb] integrate debuginfod.

Currently we have a solution for macOS to locate symbol files in the "lldb/source/Symbol/LocateSymbolFile.cpp" file in the Symbols::LocateExecutableSymbolFile(...) function:

Sat, Mar 28, 5:12 PM · Restricted Project

Fri, Mar 27

clayborg created D76964: Fix an issue where the IgnoreName function was not allowing "Class" to be looked up inside a namespace or other class..
Fri, Mar 27, 6:12 PM · Restricted Project

Thu, Mar 26

clayborg accepted D76891: [lldb-vscode] fix breakpoint result ordering.

LGTM as long as all test are passing!

Thu, Mar 26, 5:25 PM · Restricted Project
clayborg added a comment to D76872: [intel-pt] Fix existing support in LLDB.

Looks fine to me, but the original author should probably approve this

Thu, Mar 26, 12:29 PM · Restricted Project
clayborg added a comment to D76758: Augment lldb's symbol table with external symbols in Mach-O's dyld trie.

So I know the mach-o symbol table parsing code is a mess already, but it seems like this patch can be simpler if we make a std::set<lldb:addr_t> at the top of ObjectFileMachO::ParseSymtab() and every time we add a symbol that has a valid address value, add the file addr to this set. This will avoid the need to do any sorting. This std::set can be used to not add LC_FUNCTION_START entries that already have a symbol at the address, and it can be used to only add TrieEntry values that have symbols. Thoughts?

Thu, Mar 26, 12:29 PM · Restricted Project

Mon, Mar 23

clayborg added a comment to D74636: [lldb-vscode] Add inheritEnvironment option.

I would either add the option to SBLaunchInfo so it can be specified, or execute the command. If the target is created, it is setting a target specific setting. If had to pick I would add the API to SBLaunchInfo. Whenever I see something that can't be done through the API, I like to add that API if it is warranted. In our case the value in the SBLaunchInfo should probably be stored as a lldb_private::LazyBool which can have the following values:

Mon, Mar 23, 7:36 PM · Restricted Project
clayborg accepted D76529: [lldb-vscode] Add missing launchCommands entry in the package.json.
Mon, Mar 23, 7:04 PM · Restricted Project
clayborg accepted D76593: [lldb-vscode] Convert launch_info and attach_info to local variables.

Yes, this works now that we are creating the target in this function.

Mon, Mar 23, 10:55 AM · Restricted Project

Fri, Mar 20

clayborg requested changes to D76529: [lldb-vscode] Add missing launchCommands entry in the package.json.
Fri, Mar 20, 5:22 PM · Restricted Project

Thu, Mar 19

clayborg added inline comments to D74636: [lldb-vscode] Add inheritEnvironment option.
Thu, Mar 19, 6:39 PM · Restricted Project
clayborg added a comment to D76111: Create basic SBEnvironment class.

The new interface is ok for me, but there are two things I want to mention:

  • the iteration via Get{Name,Value}AtIndex is going to be slow because the underlying map (like most maps) does not have random access iterators. This is the problem I was trying to solve with the GetEntries-like API, but I agree that has its issues too.
Thu, Mar 19, 1:09 PM · Restricted Project
clayborg accepted D76314: [lldb-vscode] stop read loop after termination.

lgtm.

Thu, Mar 19, 12:30 AM · Restricted Project
clayborg added a comment to D76314: [lldb-vscode] stop read loop after termination.

Just watch the build bots carefully when you check this in!

Thu, Mar 19, 12:30 AM · Restricted Project
clayborg requested changes to D76111: Create basic SBEnvironment class.

Just some header doc cleanup before we submit. Thanks for sticking with these changes!

Thu, Mar 19, 12:30 AM · Restricted Project

Wed, Mar 18

clayborg added a comment to D76216: Improve step over performance.

Jim is the one that really needs to mark this as accepted as the thread plans are one of his many areas of expertise.

Wed, Mar 18, 11:57 PM · Restricted Project
clayborg accepted D76351: [lldb-vscode] Don't use SBLaunchInfo in request_attach.

Yep, copy and paste error!

Wed, Mar 18, 3:13 PM · Restricted Project
clayborg added inline comments to D76314: [lldb-vscode] stop read loop after termination.
Wed, Mar 18, 2:40 PM · Restricted Project
clayborg requested changes to D76111: Create basic SBEnvironment class.

We need to determine if the objects we return are copies (from SBPlatform and SBTarget), or if they are objects that will modify the environment for the platform and target respectively. If we are returning copies, we need setters on both the platform and target. If they are references, then they will just update the current environment. I think I would rather have the ability to modify them using the returned object, but I am not set on this if everyone else thinks otherwise.

Wed, Mar 18, 12:29 PM · Restricted Project

Tue, Mar 17

clayborg added a comment to D76314: [lldb-vscode] stop read loop after termination.

Does this have something to do with a multiplexor that funnels traffic through one tunnel? I am curious as to why the ReadJSON() doesn't exit after the other side closes down?

Tue, Mar 17, 5:18 PM · Restricted Project
clayborg added a comment to D76293: [WIP][DebugInfo] refactor DIE classes. Remove dependency on AsmPrinter..

I too ran into the AsmPrinter being a bit overkill for writing simple data. GSYM has a simple file writer class that just uses llvm::raw_pwrite_stream:

Tue, Mar 17, 11:16 AM · debug-info, Restricted Project

Fri, Mar 13

clayborg added inline comments to D76111: Create basic SBEnvironment class.
Fri, Mar 13, 4:45 PM · Restricted Project

Thu, Mar 12

clayborg added a comment to D75711: [NFC] Have ThreadPlans hold onto the Process & TID, rather than the Thread.

Everything looks good, just a question in inlined comment about having a thread plan hold onto a pointer to a thread. Seems dangerous

Thu, Mar 12, 4:18 PM · Restricted Project

Wed, Mar 11

clayborg added a comment to D74636: [lldb-vscode] Add inheritEnvironment option.

There's a target.inherit-env setting in lldb (which I believe also works correctly for remote launches). Could you use that instead of reimplementing the feature in vscode?

Wed, Mar 11, 3:19 PM · Restricted Project
clayborg added a comment to D75925: [lldb] reject `.debug_arange` sections with nonzero segment size.

lgtm once all formatting issues are taken care of. Pavel?

Wed, Mar 11, 3:19 PM · Restricted Project

Tue, Mar 10

clayborg added a comment to D75925: [lldb] reject `.debug_arange` sections with nonzero segment size.

Change looks good, just needs a test. Should be easy to take a simple binary that has a .debug_aranges, and run obj2yaml on it, and tweak the segment size as needed?

Tue, Mar 10, 2:13 PM · Restricted Project
clayborg added a reviewer for D75925: [lldb] reject `.debug_arange` sections with nonzero segment size: labath.
Tue, Mar 10, 2:13 PM · Restricted Project

Mar 6 2020

clayborg committed rGeb61ab1bd9af: Fix a copy and paste error that would cause a crash. (authored by clayborg).
Fix a copy and paste error that would cause a crash.
Mar 6 2020, 6:14 PM
clayborg closed D75777: Fix a copy and paste error that would cause a crash..
Mar 6 2020, 6:14 PM · Restricted Project
clayborg created D75777: Fix a copy and paste error that would cause a crash..
Mar 6 2020, 3:29 PM · Restricted Project
clayborg added a reviewer for D75777: Fix a copy and paste error that would cause a crash.: friss.
Mar 6 2020, 3:29 PM · Restricted Project
clayborg added a comment to D75711: [NFC] Have ThreadPlans hold onto the Process & TID, rather than the Thread.

As long as the keeping thread plans around for threads that aren't there is only enabled when OS plug-in is around, I am fine with this direction. One questions: do we currently only allow stepping on real threads or OS threads that are backed by real threads right now? And if an OS thread is backed by a real thread, do we associate the step plan with the OS thread ID or the real thread ID (the core)? If we use the OS thread ID, another way to potentially fix this is to know in a thread plan that we are stepping an OS thread, and avoid fetching the complete OS list of threads for non public stops, but only fetch the thread list for any OS threads that have active thread plans and any OS threads for threads that are active on a core. Then we don't end up fetching all OS threads all the time for stepping, but it does allow us to maintain and track our OS thread correctly. This would require changes to the OS plug-ins where getting the thread list needs to be able to grab only the OS threads that are on core, and we can manually fetch the OS thread info for any thread plans, and the plug-in would still need to be able to fetch the complete list on public stop events.

Mar 6 2020, 11:35 AM · Restricted Project

Mar 5 2020

clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

I just need to be able to build my binary with -fsanitize=memory. Most clangs that we have installed do not support this. Is our solution to this really to create your own buildbot and run the test just like the buildbot would? Is there a toolchain I can download from somewhere? This really makes it hard to fix issues that come up.

Building the binary with -fsanitize=memory is basically it, yes. The tricky thing about MSan is that it requires an-MSan built libcxx/libcxxabi, which which isn't trivial to bootstrap for some configurations, hence I generally just point to the "how to repro exactly the bot". :)

Mar 5 2020, 10:57 AM · Restricted Project

Mar 4 2020

clayborg committed rG4050b01ba9ec: Fix GSYM tests to run the yaml files and fix test failures on some machines. (authored by clayborg).
Fix GSYM tests to run the yaml files and fix test failures on some machines.
Mar 4 2020, 7:37 PM
clayborg committed rGffe6695acf1f: Fix buildbots with merge that didn't happen for… (authored by clayborg).
Fix buildbots with merge that didn't happen for…
Mar 4 2020, 7:37 PM
clayborg closed D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Mar 4 2020, 7:36 PM · Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

Recommitted with

Mar 4 2020, 7:35 PM · Restricted Project
clayborg reopened D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Mar 4 2020, 7:35 PM · Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

The full report you attached was enough to see what was going on. Is there a way we can enable always reporting the full output with FileCheck on the msan bots? That would help to see the full report, as we just got the first few lines in the buildbot error message.

Mar 4 2020, 5:27 PM · Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

I just need to be able to build my binary with -fsanitize=memory. Most clangs that we have installed do not support this. Is our solution to this really to create your own buildbot and run the test just like the buildbot would? Is there a toolchain I can download from somewhere? This really makes it hard to fix issues that come up.

Mar 4 2020, 4:20 PM · Restricted Project

Mar 3 2020

clayborg committed rGde2c586a12a8: Fix buildbots by including MC for StringTableBuilder. (authored by clayborg).
Fix buildbots by including MC for StringTableBuilder.
Mar 3 2020, 4:09 PM
clayborg committed rG90e40a0bdab6: Rename "llvm-gsym" to "llvm-gsymutil" and fix dependencies. (authored by clayborg).
Rename "llvm-gsym" to "llvm-gsymutil" and fix dependencies.
Mar 3 2020, 2:26 PM
clayborg closed D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Mar 3 2020, 2:25 PM · debug-info, Restricted Project

Mar 2 2020

clayborg committed rG8d41f1a02369: Fix GSYM tests to run the yaml files and fix test failures on some machines. (authored by clayborg).
Fix GSYM tests to run the yaml files and fix test failures on some machines.
Mar 2 2020, 3:41 PM
clayborg closed D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Mar 2 2020, 3:41 PM · Restricted Project
clayborg updated the diff for D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

Added architecture specific directories so when targets are not enabled, tests don't run.

Mar 2 2020, 3:39 PM · Restricted Project
clayborg committed rGe3afe5952dfa: Revert "Fix GSYM tests to run the yaml files and fix test failures on some… (authored by clayborg).
Revert "Fix GSYM tests to run the yaml files and fix test failures on some…
Mar 2 2020, 1:19 PM
clayborg added a reverting change for rG57688350adea: Fix GSYM tests to run the yaml files and fix test failures on some machines.: rGe3afe5952dfa: Revert "Fix GSYM tests to run the yaml files and fix test failures on some….
Mar 2 2020, 1:19 PM
clayborg reopened D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Need to conditionalize for ARM targets, this is failing on machines that don't have ARM targets.
Mar 2 2020, 1:19 PM · Restricted Project
clayborg committed rG57688350adea: Fix GSYM tests to run the yaml files and fix test failures on some machines. (authored by clayborg).
Fix GSYM tests to run the yaml files and fix test failures on some machines.
Mar 2 2020, 12:56 PM
clayborg closed D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Mar 2 2020, 12:56 PM · Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

Trying again with:

Mar 2 2020, 12:55 PM · Restricted Project
clayborg updated the diff for D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

Fixed an issue causing buildbots to fail where strings from files in the file table could be added in an undefined order.

Mar 2 2020, 12:55 PM · Restricted Project
clayborg planned changes to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

I figured out what was going on the build servers: function calls ordering in parameters lists is not defined which caused file table entries, which split string into directory and filename, to come out directory first, then basename, or basename then directory name. Should be an easy fix.

Mar 2 2020, 10:20 AM · Restricted Project
clayborg accepted D75454: [lldb] Make sure we don't drop asynchronous output when sourcing files.

LGTM, check remote build failure to be sure!

Mar 2 2020, 10:20 AM · Restricted Project

Feb 28 2020

clayborg reopened D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Feb 28 2020, 9:24 PM · Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

Reverted with:

Feb 28 2020, 9:20 PM · Restricted Project
clayborg committed rG5d11e7f81cb6: Revert "Fix GSYM tests to run the yaml files and fix test failures on some… (authored by clayborg).
Revert "Fix GSYM tests to run the yaml files and fix test failures on some…
Feb 28 2020, 9:19 PM
clayborg added a reverting change for rGd334ce0b5acb: Fix GSYM tests to run the yaml files and fix test failures on some machines.: rG5d11e7f81cb6: Revert "Fix GSYM tests to run the yaml files and fix test failures on some….
Feb 28 2020, 9:19 PM
clayborg committed rGd334ce0b5acb: Fix GSYM tests to run the yaml files and fix test failures on some machines. (authored by clayborg).
Fix GSYM tests to run the yaml files and fix test failures on some machines.
Feb 28 2020, 5:28 PM
clayborg closed D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Feb 28 2020, 5:28 PM · Restricted Project
clayborg added a comment to D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..

Is everyone ok with this naming?

Feb 28 2020, 4:52 PM · debug-info, Restricted Project
clayborg added a comment to D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..

These changes can easily be tested with:

./bin/llvm-lit -v ../llvm-project/llvm/test/tools/llvm-gsymutil
Feb 28 2020, 3:30 PM · Restricted Project
clayborg created D75390: Fix GSYM tests to run the yaml files and fix test failures on some machines..
Feb 28 2020, 3:30 PM · Restricted Project

Feb 27 2020

clayborg updated the diff for D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..

Remove an extra fix for triples that I will commit with a new patch.

Feb 27 2020, 11:35 PM · debug-info, Restricted Project
clayborg updated the diff for D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..

Renamed back to llvm-gsymutil for everything. So this patch now is renaming from llvm-gsym to llvm-gsymutil for the tool directory.

Feb 27 2020, 11:26 PM · debug-info, Restricted Project
clayborg added inline comments to D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Feb 27 2020, 4:38 PM · debug-info, Restricted Project
clayborg updated the diff for D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..

Removed more dependencies from the "gsymutil" tool and removed uneeded function calls.

Feb 27 2020, 4:38 PM · debug-info, Restricted Project
clayborg updated the summary of D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Feb 27 2020, 4:38 PM · debug-info, Restricted Project
clayborg added inline comments to D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Feb 27 2020, 4:29 PM · debug-info, Restricted Project
clayborg updated the summary of D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Feb 27 2020, 1:04 PM · debug-info, Restricted Project
clayborg created D75291: Rename "llvm-gsym" and "llvm-gsymutil" to "gsymutil"..
Feb 27 2020, 1:04 PM · debug-info, Restricted Project
clayborg added a comment to D74883: Add a llvm-gsymutil tool that can convert object files to GSYM and perform lookups..

dblaikie and MaskRay: thanks for the code guideline and inline comments. I will fix this in an upcoming patch.

Feb 27 2020, 11:34 AM · Restricted Project

Feb 26 2020

clayborg added a comment to D74883: Add a llvm-gsymutil tool that can convert object files to GSYM and perform lookups..

Another thing that I realized too late: Is there a good reason to all it llvm-gsymutil instead of gsymutil? We only call llvm-dwarfdump llvm-dwarfdump to disambiguate it from other dwarfdump tools.

Feb 26 2020, 2:57 PM · Restricted Project