Author: eugene
Date: Wed Jan 10 19:46:35 2018
New Revision: 322251
URL: http://llvm.org/viewvc/llvm-project?rev=322251&view=rev
Log:
Advanced guessing of rendezvous breakpoint (resubmit)
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the
Eh, no, that wasn't right. I don't know how to build and link a mach-o binary
on some random other system. So I made this a Darwin only test till I can
figure out how to do that.
Jim
> On Jan 10, 2018, at 3:09 PM, Jim Ingham wrote:
>
> I added a simple test: macosx/find-app-in-bundle. On
Author: jingham
Date: Wed Jan 10 15:32:43 2018
New Revision: 322239
URL: http://llvm.org/viewvc/llvm-project?rev=322239&view=rev
Log:
Running this on other systems won't work because I don't
know how to specifically build a MachO binary on other systems.
Modified:
lldb/trunk/packages/Python/
Author: jmolenda
Date: Wed Jan 10 15:11:29 2018
New Revision: 322237
URL: http://llvm.org/viewvc/llvm-project?rev=322237&view=rev
Log:
Remove Environment.h, test-dwarf.cpp, test-dwarf.exe
from being listed as a part of the desktop or
desktop/desktop_no_xpc Targets - they should not be
a part of a
I added a simple test: macosx/find-app-in-bundle. On non-Darwin systems it
just ensures we find the app in the
app bundle and can set a breakpoint in it. On Darwin, it also ensures we can
launch the app and hit our breakpoint.
When I get a chance I'll add an iOS app bundle and make a tricky on
Author: jingham
Date: Wed Jan 10 15:06:34 2018
New Revision: 322235
URL: http://llvm.org/viewvc/llvm-project?rev=322235&view=rev
Log:
Runs the part of the test that just finds the binary on all systems.
That should work everywhere. Then only try actually running on macosx.
Modified:
lldb/tru
Author: jingham
Date: Wed Jan 10 14:52:42 2018
New Revision: 322232
URL: http://llvm.org/viewvc/llvm-project?rev=322232&view=rev
Log:
Add a test for finding a binary in an app package.
Added:
lldb/trunk/packages/Python/lldbsuite/test/macosx/find-app-in-bundle/
lldb/trunk/packages/Python/l
The right solution seems to be adding some sort of custom GNU ABI tag to the
DWARF. I know that won't help with existing binaries, but it sounds too
expensive to set the ASM name for everything.
> On Jan 10, 2018, at 2:23 PM, Nelson Elhage via Phabricator
> wrote:
>
> nelhage added a comment
App bundles are "just directories" but they are actually different on iOS & OS
X. The most interesting part of them is a plist that gives some information
about the bundle. lldb reads that plist to figure out what the real executable
is (it is usually the bundle name minus the .app, but it doe
Author: eugene
Date: Wed Jan 10 14:25:33 2018
New Revision: 39
URL: http://llvm.org/viewvc/llvm-project?rev=39&view=rev
Log:
Revert "Advanced guessing of rendezvous breakpoint"
This reverts commit r322209, because it broke
TestNoreturnUnwind,TestInferiorAssert and TestNumThreads on i386.
nelhage added a comment.
Further evidence that the ABI tag is never stored separately:
$ strings -a -n4 test_abi_tag | grep cxx11
helloWorld_cxx11
_ZN1A16helloWorld_cxx11B5cxx11Ev
_ZN1A16helloWorld_cxx11B5cxx11Ev
Those three instances are, I presume, the `DW_AT_name`, and the
`DW_AT_lin
nelhage added a comment.
Compiling my test program with g++ and looking at `llvm-dwarfdump -all`, I can
see no reference to the ABI tag other than in the `DW_AT_linkage_name`.
Skimming the gdb source, I see references to it knowing how to *demangle* ABI
tags, but no references in the DWARF code
On Wed, Jan 10, 2018 at 2:09 PM Jim Ingham wrote:
> The only hard part of writing any kind of test for this is actually
> getting a legitimate .app into the testsuite. Doesn't seem fair to ask
> Pavel to do that, since he doesn't work on macOS...
>
> Jim
>
What exactly *is* a .app file on disk?
I understand, but having components untested is not ideal :(
On Wed, Jan 10, 2018 at 2:09 PM, Jim Ingham wrote:
> The only hard part of writing any kind of test for this is actually getting a
> legitimate .app into the testsuite. Doesn't seem fair to ask Pavel to do
> that, since he doesn't wo
The only hard part of writing any kind of test for this is actually getting a
legitimate .app into the testsuite. Doesn't seem fair to ask Pavel to do that,
since he doesn't work on macOS...
Jim
> On Jan 10, 2018, at 1:59 PM, Davide Italiano via Phabricator
> wrote:
>
> davide added a comm
aprantl added a comment.
In https://reviews.llvm.org/D40283#972622, @clayborg wrote:
> Added Adrian Prantl as a reviewer in case he has any input. Adrian: is there
> any way that a DIE is marked up with an extra attribute when the asm name is
> explicitly set? It would be great to know this fro
davide added a comment.
In https://reviews.llvm.org/D41902#972619, @zturner wrote:
> In https://reviews.llvm.org/D41902#972614, @clayborg wrote:
>
> > As long as:
> >
> > % lldb /path/to/Foo.app
> > (lldb) r
> >
> >
> > Still works, then I am fine with this. The resolve executable should find
clayborg added a comment.
And I do agree with Jim that we don't want to have to mangle the typename to
see if it matches, that is too much work.
https://reviews.llvm.org/D40283
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.
clayborg added a comment.
Added Adrian Prantl as a reviewer in case he has any input. Adrian: is there
any way that a DIE is marked up with an extra attribute when the asm name is
explicitly set? It would be great to know this from the DWARF so we don't have
to end up setting the ASM name for e
clayborg added a comment.
Sounds like finding a clang expert to clarify what Jim last asked for is the
way forward. Do a source control "blame" command and see who worked on the code
in the area of clang and maybe add them as reviewers so they can comment? I
agree with Jim that this sounds like
zturner added a comment.
In https://reviews.llvm.org/D41902#972614, @clayborg wrote:
> As long as:
>
> % lldb /path/to/Foo.app
> (lldb) r
>
>
> Still works, then I am fine with this. The resolve executable should find the
> executable down inside the app bundle (like
> "/path/to/Foo.app/Con
clayborg added a comment.
Tough to call on this one. Yes the function is dumping simple stuff, but it is
using m_arch, m_file and m_objname. It could cause crashes in multi-threaded
environments. Is the deadlock caused by an A/B lock issue?
https://reviews.llvm.org/D41909
__
clayborg added a comment.
As long as:
% lldb /path/to/Foo.app
(lldb) r
Still works, then I am fine with this. The resolve executable should find the
executable down inside the app bundle (like
"/path/to/Foo.app/Contents/MacOS/Foo" for desktop apps and
"/path/to/Foo.app/Foo" for iOS apps).
clayborg added a comment.
Looks good.
Repository:
rL LLVM
https://reviews.llvm.org/D41533
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Fix comment spacing as mentioned in inline comments and this is good to go.
Comment at: source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h:98-101
+ // Since we need to
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322209: Advanced guessing of rendezvous breakpoint (authored
by eugene, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D41533?vs=129216&id=129
Author: eugene
Date: Wed Jan 10 11:04:36 2018
New Revision: 322209
URL: http://llvm.org/viewvc/llvm-project?rev=322209&view=rev
Log:
Advanced guessing of rendezvous breakpoint
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will l
Tim added it to the Xcode project, but added it to the wrong target. All
lldb_private implementation files need to be added to the lldb-core target. We
also add all the .h files to the project alongside their .cpp files, but the .h
files for don't get added to any target (to keep Xcode's heade
Author: davide
Date: Wed Jan 10 10:53:00 2018
New Revision: 322208
URL: http://llvm.org/viewvc/llvm-project?rev=322208&view=rev
Log:
[XCodebuild] Catch up with recent changes (Environment.cpp).
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pb
> On Jan 9, 2018, at 9:31 PM, Nelson Elhage via Phabricator
> wrote:
>
> nelhage added a comment.
>
> Hey -- Is there anything I can do to move this patch forward? Would it help
> to do something like only setting the attribute if the mangled name that
> *would* be generated doesn't match t
Also, the upstream `lldb-xcode` bot is red
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/
On Wed, Jan 10, 2018 at 10:26 AM, Davide Italiano wrote:
> Picking a random commit in the `Environment` series.
> Hey Pavel, I'm currently seeing errors when building with Xcode
>
> Ld build/DebugC
Picking a random commit in the `Environment` series.
Hey Pavel, I'm currently seeing errors when building with Xcode
Ld build/DebugClang/lldb-server normal x86_64
cd /Users/davide/work/lldb
export MACOSX_DEPLOYMENT_TARGET=10.11
/Volumes/Xcode10A36a_m18A103_i16A160a_t16J145_w16R149_
fjricci added a comment.
It's definitely possible to re-design the lock holding in such a way that we
can keep this locked, but I don't want to go through all the work to do that if
there isn't any added value to doing so.
https://reviews.llvm.org/D41909
fjricci added a comment.
Actually I don't think even that is racy, because we just get a pointer to the
const char *, which is immutable anyway.
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.
fjricci added a comment.
I guess the question is whether we expect that someone will do something like
change the module's filepath while we're printing a log message with that
filepath in it.
https://reviews.llvm.org/D41909
___
lldb-commits maili
zturner added a comment.
`GetDescription` might be read only, but the code that modifies the description
isn't, right?
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
ted added a comment.
Thanks for adding me, Pavel.
Hexagon running Linux uses this plugin. These changes lgtm.
Standalone Hexagon uses its own dyld plugin; I need to look at it and see if I
want to pull any of these ideas into it.
https://reviews.llvm.org/D41533
fjricci created this revision.
fjricci added reviewers: clayborg, zturner, tberghammer.
Herald added subscribers: JDevlieghere, aprantl.
When dwarf parse logging is enabled (ie `log enable dwarf info`),
deadlocks can occur during dwarf parsing:
Thread 1:
`SymbolVendor::FindFunctions` (acquires mu
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.
This LGTM but please wait for a second opinion.
https://reviews.llvm.org/D41902
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://
tatyana-krasnukha added a comment.
There is the function GetDisasmToUse in InstructionLLVMC class that can return
nullptr. But this case is not handled in any usage. I suppose that caller
functions cannot be invoked if !DisassemblerLLVMC::IsValid(). But it still
looks dangerous for me. May be G
labath added a comment.
Committed as r322190. I've changed one more std::function to function_ref and
re-clang-formatted the patch.
Repository:
rL LLVM
https://reviews.llvm.org/D41745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322190: Handle O reply packets during qRcmd (authored by
labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D41745?vs=128991&id=129273#toc
Author: labath
Date: Wed Jan 10 06:39:08 2018
New Revision: 322190
URL: http://llvm.org/viewvc/llvm-project?rev=322190&view=rev
Log:
Handle O reply packets during qRcmd
Summary:
Gdb servers like openocd may send many $O reply packets for the client to
output during a qRcmd command sequence. Cur
Author: labath
Date: Wed Jan 10 06:17:40 2018
New Revision: 322188
URL: http://llvm.org/viewvc/llvm-project?rev=322188&view=rev
Log:
Add empty() function to the Environment class
Needed to make the previous Freebsd fix work.
Modified:
lldb/trunk/include/lldb/Utility/Environment.h
Modified:
tatyana-krasnukha updated this revision to Diff 129268.
tatyana-krasnukha added a comment.
Added "_up" suffix to each unique_ptr, renamed MCDisasmToolset to
MCDisasmInstance.
https://reviews.llvm.org/D41584
Files:
source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
source/Plugins/Disass
Author: labath
Date: Wed Jan 10 05:53:40 2018
New Revision: 322187
URL: http://llvm.org/viewvc/llvm-project?rev=322187&view=rev
Log:
Another attempt to fix FreeBsd build
the previous fix did not work because of different const qualifications
on the envp pointer.
This should resolve that (and rem
Author: tnorthover
Date: Wed Jan 10 05:32:01 2018
New Revision: 322183
URL: http://llvm.org/viewvc/llvm-project?rev=322183&view=rev
Log:
Fix Xcode build for r322174
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/v
labath created this revision.
labath added reviewers: jingham, clayborg.
Herald added a subscriber: emaste.
These were used by Host::LaunchProcess to "resolve" the executable it
was about to launch. The only parts of Platform::ResolveExecutable, which
seem to be relevant here are the FileSpec::Res
Author: labath
Date: Wed Jan 10 04:25:48 2018
New Revision: 322176
URL: http://llvm.org/viewvc/llvm-project?rev=322176&view=rev
Log:
Fix windows and freebsd builds for r322174 (Environment)
Modified:
lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp
lldb/trunk/source/Plugins/Proce
alexandreyy added a comment.
I think the stack frame structure is not correct for the PPC64be plugin.
But it is hard to say how bad it is broken and fix the plugin without testing
it.
The register numbers and stack frame structures are different from the ABI 1.9
to the ABI 2.0.
In https://revie
tatyana-krasnukha added inline comments.
Comment at: source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:1002
+ assert(m_instr_info && m_reg_info && m_subtarget_info && m_asm_info &&
+ m_context && disasm && instr_printer);
+}
labath wrote:
> this sho
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322174: Add Utility/Environment class for handling...
environments (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D41359?
Author: labath
Date: Wed Jan 10 03:57:31 2018
New Revision: 322174
URL: http://llvm.org/viewvc/llvm-project?rev=322174&view=rev
Log:
Add Utility/Environment class for handling... environments
Summary:
There was some confusion in the code about how to represent process
environment. Most of the cod
This revision was automatically updated to reflect the committed changes.
labath marked an inline comment as done.
Closed by commit rL322171: [zorg] Enable assertions on the linux lldb bot
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https:/
labath added a comment.
In https://reviews.llvm.org/D41702#971076, @jhibbits wrote:
> > @emaste, @jhibbits: do you know what's the state of ppc64 lldb support in
> > freebsd?
>
> It's broken because LLDB doesn't yet handle function descriptors, and I
> haven't yet made the effort (ENOTIME) to f
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
looks good, thanks.
https://reviews.llvm.org/D41533
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
labath accepted this revision.
labath added a comment.
Looks good to me. Just make sure to respond to all of Greg's comments as well.
Comment at: source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:989-1003
+DisassemblerLLVMC::MCDisasmToolset::MCDisasmToolset(
+std::uniq
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322167: [dotest] Remove crashinfo hook (authored by labath,
committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D41871?vs=129102&id=129224#toc
Rep
Author: labath
Date: Wed Jan 10 02:18:47 2018
New Revision: 322167
URL: http://llvm.org/viewvc/llvm-project?rev=322167&view=rev
Log:
[dotest] Remove crashinfo hook
Summary:
This used to be important when all tests were run in a single process,
but that has no longer been the case for a while. Fur
59 matches
Mail list logo
