Re: [lldb-dev] Code ownership resignation
I'm ok being co-owner of the test suite, but perhaps Todd should be there as well, and perhaps primary owner? He's done a ton of work on the multi-process infrastructure and probably is at least as familiar as I am, if not moreso with everything else. On Thu, Nov 17, 2016 at 9:23 PM Chris Lattner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Nov 16, 2016, at 3:55 PM, Enrico Granata via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > I would recommend that the community consider Jim Ingham for taking over > data formatters. He is already code owner for Objective-C runtime and > ValueObject. > > I'd like to recommend that the remaining part of Value* > (Value.h/Value.cpp) go to Greg Clayton. > > Zachary Turner has done a lot of great work on our test suite > infrastructure, and I am confident that the community would be well served > by having him serve as code owner for that portion of the project going > forward. > > These all make sense to me. Assuming no objections in the next 24 hours, > Jim, Greg, and Zachary, please update the CODE_OWNERS file, congrats! > > Thank you for all your contributions to LLDB Enrico! > > -Chris > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Code ownership resignation
On Nov 16, 2016, at 3:55 PM, Enrico Granata via lldb-dev wrote: > I would recommend that the community consider Jim Ingham for taking over data > formatters. He is already code owner for Objective-C runtime and ValueObject. > I'd like to recommend that the remaining part of Value* (Value.h/Value.cpp) > go to Greg Clayton. > > Zachary Turner has done a lot of great work on our test suite infrastructure, > and I am confident that the community would be well served by having him > serve as code owner for that portion of the project going forward. > These all make sense to me. Assuming no objections in the next 24 hours, Jim, Greg, and Zachary, please update the CODE_OWNERS file, congrats! Thank you for all your contributions to LLDB Enrico! -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server
That seems like the cleanest way to do things. It doesn’t look like the Darwin
& MacOS dynamic loaders don’t have any state that they wouldn’t correctly
re-compute mid-flight. But for instance when the shared library list goes
away, the runtime plugins might also need to get unset and reset, and they do
have a bunch of state. Not that they can’t undo that, but it is untested
whether they will or not at first go. So some caution would be warranted here.
Jim
> On Nov 17, 2016, at 9:51 AM, Greg Clayton wrote:
>
> If you call SetExecutableModule while a process is running, we probably need
> to ask the dynamic loader plug-in to update the loaded shared libraries. We
> might actually need to clear the dynamic loader and let the process load a
> new one since some dynamic loaders might use the executable to figure out if
> the dynamic loader should be loaded. It might be better to add a new function
> to Process.cpp:
>
> void
> Process::ExecutableChanged()
> {
> // Called when the executable is changed while a process is running.
> // Let the dynamic loader reload itself in case a different dynamic loader
> // might be selected with a different main executable.
> m_dyld_ap.reset();
> DynamicLoader *dyld = GetDynamicLoader();
> if (dyld)
>dyld->DidAttach();
> }
>
> This way even if breakpoints did get unresolved, the should get set again
> when the dynamic loader loads the shared libraries.
>
> Thoughts Jim?
>
>
>> On Nov 16, 2016, at 2:25 PM, Ted Woodward via lldb-dev
>> wrote:
>>
>>
>> I tried having SetExecutableModule call ModuleDidLoad after appending the
>> executable to m_images, but it didn't work. It eventually drills down to
>> call GetSectionLoadList, which is empty. Probably because the module list
>> got cleared. Any thoughts on how to clean up the new module list, and add
>> the breakpoints back?
>>
>> That leads me to think that other modules besides the executable would just
>> be lost.
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>> -Original Message-
>>> From: jing...@apple.com [mailto:jing...@apple.com]
>>> Sent: Wednesday, November 16, 2016 2:12 PM
>>> To: Ted Woodward
>>> Cc: LLDB
>>> Subject: Re: [lldb-dev] "image search-paths add" removes all breakpoints
>>> from remote server
>>>
>>>
On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev >> d...@lists.llvm.org> wrote:
Is “image search-paths add” supposed to remove all breakpoints from the
>>> remote server? I don’t think it should be doing this.
PathMappingList::Append calls Target::ImageSearchPathsChanged, which
>>> calls Target::SetExecutableModule, which calls Target::ClearModules, which
>>> removes the breakpoints. But SetExecutableModule doesn’t restore the
>>> breakpoints.
This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
>>> Packet log edited to remove chaff.
(lldb) log enable gdb-remote packets
(lldb) process launch –s
Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
(lldb) process status
Process 18766 stopped
* thread #1, name = 'factlin', stop reason = signal SIGSTOP
frame #0: 0x77ddb6b0
-> 0x77ddb6b0: movq %rsp, %rdi
0x77ddb6b3: callq 0x77ddf010
0x77ddb6b8: movq %rax, %r12
0x77ddb6bb: movl 0x2215ff(%rip), %eax
(lldb) b main
< 15> send packet: $Z0,400586,1#4a
< 6> read packet: $OK#9a
Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586
(lldb) br l
Current breakpoints:
1: name = 'main', locations = 1, resolved = 1, hit count = 0
1.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 0
(lldb) image search-paths add /local /tmp < 15> send packet:
$z0,400586,1#6a
< 6> read packet: $OK#9a
< 15> send packet: $z0,400410,1#5c
< 6> read packet: $OK#9a
(lldb) br l
Current breakpoints:
1: name = 'main', locations = 1
1.1: where = factlin`main + 22 at factorial.c:32, address =
factlin[0x00400586], unresolved, hit count = 0
(lldb) c
< 5> send packet: $c#63
Process 18766 resuming
Factorial of 10 is 3628800
< 7> read packet: $W00#b7
Process 18766 exited with status = 0 (0x)
>>>
>>> This is a distinction without much difference, but the break list output is
>>> actually telling you somebody forgot to re-install the breakpoints. Note
>>> the
>>> state went from resolved (i.e. there is a site in the targeted process for
>>> this
>>> breakpoint location) to unresolved. Still a bug, but the breakpoints aren't
>>> lying to you...
>>>
>>> When you added search paths, all the breakpoints needed to be re-set, since
>>> the symbol world m
Re: [lldb-dev] "image search-paths add" removes all breakpoints from remote server
If you call SetExecutableModule while a process is running, we probably need to
ask the dynamic loader plug-in to update the loaded shared libraries. We might
actually need to clear the dynamic loader and let the process load a new one
since some dynamic loaders might use the executable to figure out if the
dynamic loader should be loaded. It might be better to add a new function to
Process.cpp:
void
Process::ExecutableChanged()
{
// Called when the executable is changed while a process is running.
// Let the dynamic loader reload itself in case a different dynamic loader
// might be selected with a different main executable.
m_dyld_ap.reset();
DynamicLoader *dyld = GetDynamicLoader();
if (dyld)
dyld->DidAttach();
}
This way even if breakpoints did get unresolved, the should get set again when
the dynamic loader loads the shared libraries.
Thoughts Jim?
> On Nov 16, 2016, at 2:25 PM, Ted Woodward via lldb-dev
> wrote:
>
>
> I tried having SetExecutableModule call ModuleDidLoad after appending the
> executable to m_images, but it didn't work. It eventually drills down to call
> GetSectionLoadList, which is empty. Probably because the module list got
> cleared. Any thoughts on how to clean up the new module list, and add the
> breakpoints back?
>
> That leads me to think that other modules besides the executable would just
> be lost.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Wednesday, November 16, 2016 2:12 PM
>> To: Ted Woodward
>> Cc: LLDB
>> Subject: Re: [lldb-dev] "image search-paths add" removes all breakpoints
>> from remote server
>>
>>
>>> On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev > d...@lists.llvm.org> wrote:
>>>
>>> Is “image search-paths add” supposed to remove all breakpoints from the
>> remote server? I don’t think it should be doing this.
>>>
>>> PathMappingList::Append calls Target::ImageSearchPathsChanged, which
>> calls Target::SetExecutableModule, which calls Target::ClearModules, which
>> removes the breakpoints. But SetExecutableModule doesn’t restore the
>> breakpoints.
>>>
>>>
>>>
>>> This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
>> Packet log edited to remove chaff.
>>>
>>> (lldb) log enable gdb-remote packets
>>> (lldb) process launch –s
>>> Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
>>> (lldb) process status
>>> Process 18766 stopped
>>> * thread #1, name = 'factlin', stop reason = signal SIGSTOP
>>>frame #0: 0x77ddb6b0
>>> -> 0x77ddb6b0: movq %rsp, %rdi
>>>0x77ddb6b3: callq 0x77ddf010
>>>0x77ddb6b8: movq %rax, %r12
>>>0x77ddb6bb: movl 0x2215ff(%rip), %eax
>>> (lldb) b main
>>> < 15> send packet: $Z0,400586,1#4a
>>> < 6> read packet: $OK#9a
>>> Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
>>> 0x00400586
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = factlin`main + 22 at factorial.c:32, address =
>>> 0x00400586, resolved, hit count = 0
>>> (lldb) image search-paths add /local /tmp < 15> send packet:
>>> $z0,400586,1#6a
>>> < 6> read packet: $OK#9a
>>> < 15> send packet: $z0,400410,1#5c
>>> < 6> read packet: $OK#9a
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1
>>> 1.1: where = factlin`main + 22 at factorial.c:32, address =
>>> factlin[0x00400586], unresolved, hit count = 0
>>> (lldb) c
>>> < 5> send packet: $c#63
>>> Process 18766 resuming
>>> Factorial of 10 is 3628800
>>> < 7> read packet: $W00#b7
>>> Process 18766 exited with status = 0 (0x)
>>
>> This is a distinction without much difference, but the break list output is
>> actually telling you somebody forgot to re-install the breakpoints. Note the
>> state went from resolved (i.e. there is a site in the targeted process for
>> this
>> breakpoint location) to unresolved. Still a bug, but the breakpoints aren't
>> lying to you...
>>
>> When you added search paths, all the breakpoints needed to be re-set, since
>> the symbol world might have changed. But apparently only the removal part
>> is getting done.
>>
>> Jim
>>
>>
>>>
>>> As you can see, the breakpoint at main was removed on lldb-server, but
>> shows as active in the breakpoint list. When I continue, the breakpoint isn’t
>> hit, and the target runs to completion.
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
