Re: [lldb-dev] [cfe-dev] [llvm-dev] Fwd: Raising CMake minimum version to 3.4.3
Adding lldb-dev to the loop. I don't think there should be major issues there as lldb supports a strict subset targets, just making sure everyone is aware of the plans. Our team manages a couple of lldb buildbots still using cmake 2.8. We'll get started on upgrading them though. pl On 5 May 2016 at 01:08, Galina Kistanova via cfe-dev wrote: > This sounds good to me. > I have planned the update. > > Thanks > > Galina > > On Wed, May 4, 2016 at 9:50 AM, Mike Edwards via llvm-dev > wrote: >> >> Chris, >> We have upgrade our bots (both internal and external) to CMake 3.5.2. So >> we are good to go. >> >> -Mike >> >> On Tue, May 3, 2016 at 12:29 PM, Chris Bieneman via llvm-dev >> wrote: >>> >>> Renato, >>> >>> This approach sounds great to me. >>> >>> Chris M let me know separately that GreenDragon is on CMake 3.5. >>> >>> I belive Galina and Takumi maintain the largest chunk of remaining public >>> bots. Do either of you have any thoughts on this? >>> >>> Thanks, >>> -Chris >>> >>> > On May 3, 2016, at 11:19 AM, Renato Golin >>> > wrote: >>> > >>> > On 3 May 2016 at 17:07, Chris Bieneman via cfe-dev >>> > wrote: >>> >> Since there seems to be no strong objections remaining I’d like to >>> >> propose the following timeline and process: >>> >> >>> >> 4/23 - I will send another follow-up email reminding everyone of this >>> >> change and timeline >>> >> 4/30 - I will send a final notice an hour before making the change to >>> >> the LLVM, Clang, Compiler-RT, Clang-Tools-Extra, LibCXX, LibCXXABI and >>> >> Test-Suite repos >>> >> >>> >> During the week of 4/30 I will revert as necessary if bots fail. >>> >> Hopefully having the change permanently landed by the middle of the week. >>> >> >>> >> Does this sound agreeable to everyone? >>> > >>> > I'd like to propose a different approach. How about we do this the >>> > other way around? Maybe we should try the "move first, fix later", >>> > than the "break first, despair later". >>> > >>> > This week we (Linaro) have finished our buildbot migration, all of >>> > them running on CMake 3.4.3. I'd like to see if other bot maintainers >>> > could take the same effort before a certain date. >>> > >>> > So, we can still have the same dates (in May, of course), but with >>> > different "labels": >>> > >>> > Soon, you send an announcement: >>> > * Saying the consensus is to move to CMake 3.4.3 as well as a >>> > compiled CMake for all platforms, >>> > * That the technical reason is strong enough to do so, even if it >>> > incurs more work to some people, >>> > * That *ALL* bot owners should migrate as soon as possible (no later >>> > than 30th). >>> > >>> > On 23rd, you send a reminder to the list informing all bot owners that >>> > time is running out. >>> > * If they can't do it, who could help them >>> > * If they need push in the CMake community, or a new stable release, >>> > it's better to have it now than then >>> > >>> > On 30th, you do the migration as you proposed. >>> > >>> > It's all the same, but with the difference that we're involving all >>> > bot owners, and hopefully not having to revert too many times such a >>> > troublesome change (CMake changes always mess up the bots anyway). >>> > >>> > Anyway, for ARM/AArch64, we're good to go. >>> > >>> > cheers, >>> > --renato >>> >>> ___ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
I'm stepping over the first line of a libcxx test (source
https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condit
ion/thread.condition.condvar/wait.pass.cpp ). The first line has an inlined
function call. I expect lldb to step over the breakpoint, run to the end of
the range that sets up the inlined function call, run through the inlined
function call, then run to the end of the line. Instead, it runs to the
inlined call, then stops.
I'm running lldb on Windows, debugging a Hexagon application that was built
on Linux. I'm using the target.source-map setting to let me see source.
The problem is in ThreadPlanStepRange::InRange. It checks to see if we're
still on the same line by comparing the filename in the Stepping Plan's line
entry to the filename in the current frame's line entry.
m_addr_context.line_entry.file has been normalized by the value in
target.source-map, but new_context.line_entry.file hasn't, so they're not
the same, even though they should be.
SymbolContext
new_context(frame->GetSymbolContext(eSymbolContextEverything));
if (m_addr_context.line_entry.IsValid() &&
new_context.line_entry.IsValid())
{
if (m_addr_context.line_entry.file ==
new_context.line_entry.file)
{
Either both should use target.source-map, or neither should. How do I run
new_context.line_entry.file through the target.source-map normalization?
Ted
--
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
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
> wrote:
>
> I’m stepping over the first line of a libcxx test (source
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
> ). The first line has an inlined function call. I expect lldb to step over
> the breakpoint, run to the end of the range that sets up the inlined function
> call, run through the inlined function call, then run to the end of the line.
> Instead, it runs to the inlined call, then stops.
>
> I’m running lldb on Windows, debugging a Hexagon application that was built
> on Linux. I’m using the target.source-map setting to let me see source.
>
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re
> still on the same line by comparing the filename in the Stepping Plan’s line
> entry to the filename in the current frame’s line entry.
> m_addr_context.line_entry.file has been normalized by the value in
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the
> same, even though they should be.
>
> SymbolContext
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() &&
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>
>
> Either both should use target.source-map, or neither should. How do I run
> new_context.line_entry.file through the target.source-map normalization?
It doesn't seem right to me that when symbols are handed out they have the
source map applied to their file spec's. After all, then you could get into
problems like: somebody started a step so we recorded m_addr_context. Then
their step was interrupted (say by hitting a breakpoint) and the user added a
source mapping. Then we stop in a frame from the same module, and now the
SymbolContext that the step plan stored (m_addr_context) has a different path
than the one in the frame when we get to it. Checking every time you compared
file specs seems very error prone, we shouldn't do it that way. I guess if the
FileSpec == handled this it would be odd but not too bad. But that seems like
it would result in a lot of unnecessary work. I think it would be better to
only do source map path conversion when sources are looked up, and maybe when
paths are printed. For symbols we should stick to what the debug info says.
Jim
>
> Ted
>
> --
> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
Symbols are being remapped. StackFrame::GetSymbolContext does this:
m_sc.line_entry = sc.line_entry;
if (m_sc.target_sp)
{
// Be sure to apply and file remappings to our file and
line
// entries when handing out a line entry
FileSpec new_file_spec;
if (m_sc.target_sp->GetSourcePathMap().FindFile
(m_sc.line_entry.file, new_file_spec))
m_sc.line_entry.file = new_file_spec;
}
This code gets called if the StackFrame ctor is called with the SymbolContext =
nullptr, but this is skipped if the SymbolContext is valid. All new StackFrames
in StackFrameList are done with a null SC, except for an inlined frame. In that
case, StackFrameList::GetFramesUpTo calls
SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo
does not remap it like StackFrame::GetSymbolContext does. Then it creates a new
StackFrame with the SC.
Adding this before the new StackFrame fixes the issue:
if (target_sp)
{
// Be sure to apply and file remappings to our file and
line
// entries when handing out a line entry
FileSpec new_file_spec;
if
(target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file,
new_file_spec))
next_frame_sc.line_entry.file = new_file_spec;
}
I've put up a patch on Phabricator with Jim as reviewer.
--
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: Friday, May 06, 2016 2:41 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context
and target.source-map setting
> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
> wrote:
>
> I’m stepping over the first line of a libcxx test (source
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
> ). The first line has an inlined function call. I expect lldb to step over
> the breakpoint, run to the end of the range that sets up the inlined function
> call, run through the inlined function call, then run to the end of the line.
> Instead, it runs to the inlined call, then stops.
>
> I’m running lldb on Windows, debugging a Hexagon application that was built
> on Linux. I’m using the target.source-map setting to let me see source.
>
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re
> still on the same line by comparing the filename in the Stepping Plan’s line
> entry to the filename in the current frame’s line entry.
> m_addr_context.line_entry.file has been normalized by the value in
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the
> same, even though they should be.
>
> SymbolContext
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() &&
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>
>
> Either both should use target.source-map, or neither should. How do I run
> new_context.line_entry.file through the target.source-map normalization?
It doesn't seem right to me that when symbols are handed out they have the
source map applied to their file spec's. After all, then you could get into
problems like: somebody started a step so we recorded m_addr_context. Then
their step was interrupted (say by hitting a breakpoint) and the user added a
source mapping. Then we stop in a frame from the same module, and now the
SymbolContext that the step plan stored (m_addr_context) has a different path
than the one in the frame when we get to it. Checking every time you compared
file specs seems very error prone, we shouldn't do it that way. I guess if the
FileSpec == handled this it would be odd but not too bad. But that seems like
it would result in a lot of unnecessary work. I think it would be better to
only do source map path conversion when sources are looked up, and maybe when
paths are printed. For symbols we should stick to what the debug info says.
Jim
>
> Ted
>
> --
> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
Why are we remapping the FileSpecs in SymbolContext's we are handing out? That
seems to me a bad idea. It means that every time I want to do a FileSpec
compare between the LineEntry FileSpec's that I get at from stack frames at two
different times, I have to remember to re-apply the SourceMap to the file spec
I've stored away before doing the compare. After all, the user might have
changed the source map and thus the file spec we are handing out. That seems
very error prone. And we can't handle that in the FileSpec "==" operator
because FileSpec's don't have Targets, so they have no way of getting to the
map.
Wouldn't it be better to use the source maps when we print filenames and look
for actual source files, and leave the symbol context FileSpec's in some
canonical form we know won't change over time?
Jim
> On May 6, 2016, at 3:05 PM, Ted Woodward wrote:
>
> Symbols are being remapped. StackFrame::GetSymbolContext does this:
>
>m_sc.line_entry = sc.line_entry;
>if (m_sc.target_sp)
>{
>// Be sure to apply and file remappings to our file
> and line
>// entries when handing out a line entry
>FileSpec new_file_spec;
>if (m_sc.target_sp->GetSourcePathMap().FindFile
> (m_sc.line_entry.file, new_file_spec))
>m_sc.line_entry.file = new_file_spec;
>}
>
> This code gets called if the StackFrame ctor is called with the SymbolContext
> = nullptr, but this is skipped if the SymbolContext is valid. All new
> StackFrames in StackFrameList are done with a null SC, except for an inlined
> frame. In that case, StackFrameList::GetFramesUpTo calls
> SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo
> does not remap it like StackFrame::GetSymbolContext does. Then it creates a
> new StackFrame with the SC.
>
> Adding this before the new StackFrame fixes the issue:
>if (target_sp)
>{
>// Be sure to apply and file remappings to our file
> and line
>// entries when handing out a line entry
>FileSpec new_file_spec;
>if
> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file,
> new_file_spec))
>next_frame_sc.line_entry.file = new_file_spec;
>}
>
> I've put up a patch on Phabricator with Jim as reviewer.
>
> --
> 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: Friday, May 06, 2016 2:41 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context
> and target.source-map setting
>
>
>> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
>> wrote:
>>
>> I’m stepping over the first line of a libcxx test (source
>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>> ). The first line has an inlined function call. I expect lldb to step over
>> the breakpoint, run to the end of the range that sets up the inlined
>> function call, run through the inlined function call, then run to the end of
>> the line. Instead, it runs to the inlined call, then stops.
>>
>> I’m running lldb on Windows, debugging a Hexagon application that was built
>> on Linux. I’m using the target.source-map setting to let me see source.
>>
>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re
>> still on the same line by comparing the filename in the Stepping Plan’s line
>> entry to the filename in the current frame’s line entry.
>> m_addr_context.line_entry.file has been normalized by the value in
>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not
>> the same, even though they should be.
>>
>>SymbolContext
>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>if (m_addr_context.line_entry.IsValid() &&
>> new_context.line_entry.IsValid())
>>{
>>if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>{
>>
>>
>> Either both should use target.source-map, or neither should. How do I run
>> new_context.line_entry.file through the target.source-map normalization?
>
>
>
> It doesn't seem right to me that when symbols are handed out they have the
> source map applied to their file spec's. After all, then you could get into
> problems like: somebody started a step so we recorded m_addr_context. Then
> their step was interrupted (say by hitting a breakpoint) and the user added a
> source mapping. Then we stop in a frame from the same module
Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting
Another alternative would be to make the LineEntry hold both the remapped &
original file spec, and add an API to get the "original FileSpec". Then
anybody who is holding onto a line entry or file spec derived therefrom will
know to compare the original file spec, since the remapped one is unreliable.
Probably should move the remapping to the LineEntry
(LineEntry::ApplyFileMappings(Target &target) so it is clear who is in charge
of this.
Note, you absolutely should never use SourceMaps to remap FileSpecs that are in
the module's debug information, since these modules are shared among all the
Debugger's, and the Debuggers could have different SourceMaps. So by putting
this explicitly in the LineEntry - which is not something we use to store line
information, it's just something we cons up to hand out when requested - it
might make that requirement clearer.
Jim
> On May 6, 2016, at 3:49 PM, Jim Ingham via lldb-dev
> wrote:
>
> Why are we remapping the FileSpecs in SymbolContext's we are handing out?
> That seems to me a bad idea. It means that every time I want to do a
> FileSpec compare between the LineEntry FileSpec's that I get at from stack
> frames at two different times, I have to remember to re-apply the SourceMap
> to the file spec I've stored away before doing the compare. After all, the
> user might have changed the source map and thus the file spec we are handing
> out. That seems very error prone. And we can't handle that in the FileSpec
> "==" operator because FileSpec's don't have Targets, so they have no way of
> getting to the map.
>
> Wouldn't it be better to use the source maps when we print filenames and look
> for actual source files, and leave the symbol context FileSpec's in some
> canonical form we know won't change over time?
>
> Jim
>
>
>> On May 6, 2016, at 3:05 PM, Ted Woodward wrote:
>>
>> Symbols are being remapped. StackFrame::GetSymbolContext does this:
>>
>> m_sc.line_entry = sc.line_entry;
>> if (m_sc.target_sp)
>> {
>> // Be sure to apply and file remappings to our file
>> and line
>> // entries when handing out a line entry
>> FileSpec new_file_spec;
>> if (m_sc.target_sp->GetSourcePathMap().FindFile
>> (m_sc.line_entry.file, new_file_spec))
>> m_sc.line_entry.file = new_file_spec;
>> }
>>
>> This code gets called if the StackFrame ctor is called with the
>> SymbolContext = nullptr, but this is skipped if the SymbolContext is valid.
>> All new StackFrames in StackFrameList are done with a null SC, except for an
>> inlined frame. In that case, StackFrameList::GetFramesUpTo calls
>> SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo
>> does not remap it like StackFrame::GetSymbolContext does. Then it creates a
>> new StackFrame with the SC.
>>
>> Adding this before the new StackFrame fixes the issue:
>> if (target_sp)
>> {
>> // Be sure to apply and file remappings to our file
>> and line
>> // entries when handing out a line entry
>> FileSpec new_file_spec;
>> if
>> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file,
>> new_file_spec))
>> next_frame_sc.line_entry.file = new_file_spec;
>> }
>>
>> I've put up a patch on Phabricator with Jim as reviewer.
>>
>> --
>> 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: Friday, May 06, 2016 2:41 PM
>> To: Ted Woodward
>> Cc: LLDB
>> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol
>> context and target.source-map setting
>>
>>
>>> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev
>>> wrote:
>>>
>>> I’m stepping over the first line of a libcxx test (source
>>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>>> ). The first line has an inlined function call. I expect lldb to step over
>>> the breakpoint, run to the end of the range that sets up the inlined
>>> function call, run through the inlined function call, then run to the end
>>> of the line. Instead, it runs to the inlined call, then stops.
>>>
>>> I’m running lldb on Windows, debugging a Hexagon application that was built
>>> on Linux. I’m using the target.source-map setting to let me see source.
>>>
>>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re
>>> still on the same line by comparing the filename in the Stepping Plan’s
>>> line entry to the filename in the current frame’s line
