[lldb-dev] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

Hi,

I have been working on a compiler issue, where instructions associated to
the function prolog are assigned line information, causing the debugger to
show incorrectly the beginning of the function body.

For a full description, please see:

https://reviews.llvm.org/D37625
https://reviews.llvm.org/rL313047

The submitted patch caused some LLDB tests to fail. I have attached the log
failure.

I have no knowledge about the test framework used by LLDB.

What is the best way to proceed in this case?

Thanks very much for your feedback.

Carlos Enciso
++ config=(${1//,/ })
++ compiler=totclang
++ arch=i386
++ trap clean EXIT
++ '[' totclang == totclang ']'
++ compiler=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang
++ '[' / == / ']'
+++ dirname /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang
++ ccdir=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/..
++ export 
LD_LIBRARY_PATH=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib64:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib32:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib
++ 
LD_LIBRARY_PATH=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib64:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib32:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib
++ cc_log=totclang
++ 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py
 --executable 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb -A i386 -C 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang -v -s 
logs-totclang-i386 -u CXXFLAGS -u CFLAGS --env ARCHIVER=ar --env 
OBJCOPY=objcopy --channel 'gdb-remote packets' --channel 'lldb all' 
--skip-category lldb-mi
Testing: 597 test suites, 32 threads

  0 out of 597 test suites processed - 
['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py',
 '--executable', 
'/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb', '-A', 
'i386', '-C', 
'/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang', '-v', 
'-s', 'logs-totclang-i386', '-u', 'CXXFLAGS', '-u', 'CFLAGS', '--env', 
'ARCHIVER=ar', '--env', 'OBJCOPY=objcopy', '--channel', 'gdb-remote packets', 
'--channel', 'lldb all', '--skip-category', 'lldb-mi']

  1 out of 597 test suites processed - TestDarwinNSLogOutput.py
  2 out of 597 test suites processed - TestSequenceFunctions.py
  3 out of 597 test suites processed - TestBundleWithDotInFilename.py
  4 out of 597 test suites processed - TestAddDsymMidExecutionCommand.py
  5 out of 597 test suites processed - TestUniversal.py 
  6 out of 597 test suites processed - TestAppleTypesIsProduced.py  
  7 out of 597 test suites processed - TestDefaultCacheLineSize.py  
  8 out of 597 test suites processed - TestOrderFile.py 
  9 out of 597 test suites processed - TestSafeFuncCalls.py 
 10 out of 597 test suites processed - TestInterruptThreadNames.py  
 11 out of 597 test suites processed - TestAddDsymCommand.py
 12 out of 597 test suites processed - TestDeepBundle.py
 13 out of 597 test suites processed - TestQueues.py
 14 out of 597 test suites processed - TestIndirectSymbols.py   
 15 out of 597 test suites processed - TestSampleTest.py
 16 out of 597 test suites processed - TestMultipleTargets.py   
 17 out of 597 test suites processed - TestTargetSymbolsAddCommand.py   
 18 out of 597 test suites processed - TestImageListMultiArchitecture.py
 19 out of 597 test suites processed - TestPublicAPIHeaders.py  
 20 out of 597 test suites processed - TestMiniDump.py  
 21 out of 597 test suites processed - TestGCore.py 
 22 out of 597 test suites processed - TestLinuxCoreThreads.py  
 23 out of 597 test suites processed - TestWow64MiniDump.py 
 24 out of 597 test suites processed - TestPluginCommands.py
 25 out of 597 test suites processed - TestJITLoaderGDB.py  
 26 out of 597 test suites processed - TestLinuxCore.py 
 27 out of 597 test suites processed - TestBackticksWithoutATarget.py   
 28 out of 597 test suites processed - TestBuiltinTrap.py   
 29 out of 597 test suites processed - TestMultithreaded.py 
 30 out of 597 test suites processed - TestMemoryHistory.py 
 31 out of 597 test suites processed - TestSingleQuoteInFilename.py 
 32 out of 597 test suites processed - TestConcurrentManyWatchpoints.py 
 33 out of 597 test suites processed - TestMemoryCache.py   
 34 out of 597 test suites processed - TestCommandRegex.py  
 35 out of 597 test suites processed - TestMemoryRead.py
 36 out of 597 test suites processed - TestPythonOSPlugin.py
 37 out of 597

Re: [lldb-dev] Prologue instructions having line information

[Tamas Berghammer via lldb-dev]

Hi Carlos,

Thank your for looking into the LLDB failure. I looked into it briefly and
the issue is that we have have 2 function f and g where g is inlined into f
as the first call and this causes the first non-prologue line entry of f to
be inside the address range of g what means that when we step info f from
outside we will end up inside g instead. Previously the first line entry
for f matched with the start address of the inlined copy of g where LLDB
was able to handle the stepping properly.

For the concrete example you should compile
https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp
with
"/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0
-fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe
that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
first line entry after "Set prologue_end to true" is at 0x8048796 while
previously it was at 0x8048793.

Tamas

On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I have been working on a compiler issue, where instructions associated to
> the function prolog are assigned line information, causing the debugger to
> show incorrectly the beginning of the function body.
>
> For a full description, please see:
>
> https://reviews.llvm.org/D37625
> https://reviews.llvm.org/rL313047
>
> The submitted patch caused some LLDB tests to fail. I have attached the
> log failure.
>
> I have no knowledge about the test framework used by LLDB.
>
> What is the best way to proceed in this case?
>
> Thanks very much for your feedback.
>
> Carlos Enciso
>
>
>
> ___
> 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] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Greg Clayton via lldb-dev]

Seems like this class was added for testing. RegisterInfoInterface is a class 
that creates a common API for getting lldb_private::RegisterInfo structures.  

A RegisterContext_ class uses one of these to be able to create a 
buffer large enough to store all registers defined in the RegisterInfoInterface 
and will actually read/write there registers to/from the debugged process. 
RegisterContext also caches registers values so they don't get read multiple 
times when the process hasn't resumed. A RegisterContext subclass is needed for 
each architecture so we can dynamically tell LLDB what the registers look like 
for a given architecture. It also provides abstractions by letting each 
register define its registers numbers for Compilers, DWARF, and generic 
register numbers like PC, SP, FP, return address, and flags registers. This 
allows the generic part of LLDB to say "I need you to give me the PC register 
for this thread" and we don't need to know that the register is "eip" on x86, 
"rip" on x86_64, "r15" on ARM. RegisterContext classes can also determine how 
registers are read/written: one at a time, or "get all general purpose regs" 
and "get all FPU regs". So if someone asks a RegisterContext to read the PC, it 
might go read all GPR regs and then mark them all as valid in the register 
context buffer cache, so if someone subsequently asks for SP, it will be 
already cached. 

So RegisterInfoInterface defines a common way that many RegisterContext classes 
can inherit from in order to give out the lldb_private::RegisterInfo (which is 
required by all subclasses of RegisterContext) info for a register context, and 
RegisterContext is the one that actually will interface with the debugged 
process in order to read/write and cache those registers as efficiently as 
possible for the current program being debugged.

> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev  
> wrote:
> 
> Hi,
> 
> When deriving RegisterContext_, why some platforms (Arch+OS)
> are deriving it from lldb_private::RegisterContext while others are
> deriving from lldb_private::RegisterInfoInterface or in other words
> how to decide on the base class to derive from between those two and
> what are the implications?
> 
> Thanks,
> Ramana
> ___
> 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] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

Hi Tamas,

Thanks very much for your reply and the useful information.

In order to properly test my changes (I have another Debug Information
ready for submission) I would like be able to build LLDB on my local
machine. Once I reach that point, I will follow the process you described
(compile calling.cpp) and I would let you know my progress.

Best regards,
Carlos

On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer 
wrote:

> Hi Carlos,
>
> Thank your for looking into the LLDB failure. I looked into it briefly and
> the issue is that we have have 2 function f and g where g is inlined into f
> as the first call and this causes the first non-prologue line entry of f to
> be inside the address range of g what means that when we step info f from
> outside we will end up inside g instead. Previously the first line entry
> for f matched with the start address of the inlined copy of g where LLDB
> was able to handle the stepping properly.
>
> For the concrete example you should compile https://github.com/llv
> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
> packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp 
> with
> "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0
> -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe
> that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
> inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
> first line entry after "Set prologue_end to true" is at 0x8048796 while
> previously it was at 0x8048793.
>
> Tamas
>
> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I have been working on a compiler issue, where instructions associated to
>> the function prolog are assigned line information, causing the debugger to
>> show incorrectly the beginning of the function body.
>>
>> For a full description, please see:
>>
>> https://reviews.llvm.org/D37625
>> https://reviews.llvm.org/rL313047
>>
>> The submitted patch caused some LLDB tests to fail. I have attached the
>> log failure.
>>
>> I have no knowledge about the test framework used by LLDB.
>>
>> What is the best way to proceed in this case?
>>
>> Thanks very much for your feedback.
>>
>> Carlos Enciso
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prologue instructions having line information

[Jim Ingham via lldb-dev]

This is only tangential, but it is a known bug that when we stop on a line that 
starts an inlined block we don't pretend we're in the outer function first, so 
the user can "step-in" to the inlined function.  This is particularly notable 
when you have several nested levels of inlining starting at the same address, 
we say the naive thing - that we're in the innermost function, rather than 
setting up a set of fake step-in's that mirror the inline nesting.  If somebody 
wants to take a whack at fixing that it would be great.  Shouldn't be too hard. 
 We need to do other kinds of fakery as well, for instance if you have three 
levels of nested inlining and you set a breakpoint by specifying the middle 
function, then when you hit that breakpoint we should pretend we've just 
stepped into the middle function.

We handle these fictions with straight-line stepping when it encounters 
inlining pretty much okay.  But when we're just running to an address (and 
apparently when pushing past the prologue) we're not telling the right story.

Jim

> On Sep 14, 2017, at 3:20 AM, Tamas Berghammer via lldb-dev 
>  wrote:
> 
> Hi Carlos,
> 
> Thank your for looking into the LLDB failure. I looked into it briefly and 
> the issue is that we have have 2 function f and g where g is inlined into f 
> as the first call and this causes the first non-prologue line entry of f to 
> be inside the address range of g what means that when we step info f from 
> outside we will end up inside g instead. Previously the first line entry for 
> f matched with the start address of the inlined copy of g where LLDB was able 
> to handle the stepping properly.
> 
> For the concrete example you should compile 
> https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp
>  with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0 
> -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe that 
> caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the inlined 
> inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the first line 
> entry after "Set prologue_end to true" is at 0x8048796 while previously it 
> was at 0x8048793.
> 
> Tamas
> 
> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev 
>  wrote:
> Hi,
> 
> I have been working on a compiler issue, where instructions associated to the 
> function prolog are assigned line information, causing the debugger to show 
> incorrectly the beginning of the function body.
> 
> For a full description, please see:
> 
> https://reviews.llvm.org/D37625
> https://reviews.llvm.org/rL313047
> 
> The submitted patch caused some LLDB tests to fail. I have attached the log 
> failure.
> 
> I have no knowledge about the test framework used by LLDB.
> 
> What is the best way to proceed in this case?
> 
> Thanks very much for your feedback.
> 
> Carlos Enciso
> 
> 
> 
> ___
> 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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prologue instructions having line information

[Chris Quenelle via lldb-dev]

Have you guys considered going all the way and recording multiple layers
of line information for the same range of instructions, and allowing the user 
to jump up and down through the not-really-there function calls?  That seems
like a very usefuil features for looking at optimized code.  You’d need an
extension to the dwarf information of some kind.

Chris



> On Sep 14, 2017, at 11:29 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> This is only tangential, but it is a known bug that when we stop on a line 
> that starts an inlined block we don't pretend we're in the outer function 
> first, so the user can "step-in" to the inlined function.  This is 
> particularly notable when you have several nested levels of inlining starting 
> at the same address, we say the naive thing - that we're in the innermost 
> function, rather than setting up a set of fake step-in's that mirror the 
> inline nesting.  If somebody wants to take a whack at fixing that it would be 
> great.  Shouldn't be too hard.  We need to do other kinds of fakery as well, 
> for instance if you have three levels of nested inlining and you set a 
> breakpoint by specifying the middle function, then when you hit that 
> breakpoint we should pretend we've just stepped into the middle function.
> 
> We handle these fictions with straight-line stepping when it encounters 
> inlining pretty much okay.  But when we're just running to an address (and 
> apparently when pushing past the prologue) we're not telling the right story.
> 
> Jim
> 
>> On Sep 14, 2017, at 3:20 AM, Tamas Berghammer via lldb-dev 
>>  wrote:
>> 
>> Hi Carlos,
>> 
>> Thank your for looking into the LLDB failure. I looked into it briefly and 
>> the issue is that we have have 2 function f and g where g is inlined into f 
>> as the first call and this causes the first non-prologue line entry of f to 
>> be inside the address range of g what means that when we step info f from 
>> outside we will end up inside g instead. Previously the first line entry for 
>> f matched with the start address of the inlined copy of g where LLDB was 
>> able to handle the stepping properly.
>> 
>> For the concrete example you should compile 
>> https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp
>>  with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0 
>> -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe that 
>> caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the inlined 
>> inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the first 
>> line entry after "Set prologue_end to true" is at 0x8048796 while previously 
>> it was at 0x8048793.
>> 
>> Tamas
>> 
>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev 
>>  wrote:
>> Hi,
>> 
>> I have been working on a compiler issue, where instructions associated to 
>> the function prolog are assigned line information, causing the debugger to 
>> show incorrectly the beginning of the function body.
>> 
>> For a full description, please see:
>> 
>> https://reviews.llvm.org/D37625
>> https://reviews.llvm.org/rL313047
>> 
>> The submitted patch caused some LLDB tests to fail. I have attached the log 
>> failure.
>> 
>> I have no knowledge about the test framework used by LLDB.
>> 
>> What is the best way to proceed in this case?
>> 
>> Thanks very much for your feedback.
>> 
>> Carlos Enciso
>> 
>> 
>> 
>> ___
>> 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
> 
> ___
> 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] Prologue instructions having line information

[Jim Ingham via lldb-dev]

This is supported (admittedly a little awkwardly) in DWARF with the 
DW_TAG_inline_subroutine DIE's in the  debug_info section of the DWARF.  They 
can expresses the nesting fully.  

I think we have all the data we need to do this right (*).

The missing part is making the right decision of which is the right frame in 
this virtual frame stack to choose depending on how you hit it.  For instance, 
when skipping the prologue to the beginning of the inline function, you really 
should choose the function whose prologue you were skipping, and then allow a 
"step-in" to get you into the function.  If you stop because of a breakpoint 
you should choose the frame in the virtual stack that the breakpoint was set 
in.  Etc.  I did this for straight line stepping.  So for instance if you are 
sitting at an instruction that is the start of a nested set of inlined 
functions, and do "step-in", lldb will not move the pc, but pretend it has 
stepped into the first of the inlined stacks.  Another step-in will get you to 
the next one, etc.  But there are a bunch of corner cases I haven't gotten to 
yet.

(*) Because you need to update this information in two places (whichever line 
gets chosen for the debug_line section, and the ranges of the 
DW_TAG_inline_subroutines, it allows an opportunity for fumbles that seems to 
trip up clang.  This has gotten better over time, but we still have a lot of 
reports where the range of lines in the line table and that in the debug_info 
don't match, making it very hard for lldb to figure out where it is.

It would be better to have this all expressed in one place so it would be 
easier to keep it coherent.  But that isn't necessary for lldb's purposes.

Jim


> On Sep 14, 2017, at 3:20 PM, Chris Quenelle  wrote:
> 
> Have you guys considered going all the way and recording multiple layers
> of line information for the same range of instructions, and allowing the user 
> to jump up and down through the not-really-there function calls?  That seems
> like a very usefuil features for looking at optimized code.  You’d need an
> extension to the dwarf information of some kind.
> 
> Chris
> 
> 
> 
>> On Sep 14, 2017, at 11:29 AM, Jim Ingham via lldb-dev 
>>  wrote:
>> 
>> This is only tangential, but it is a known bug that when we stop on a line 
>> that starts an inlined block we don't pretend we're in the outer function 
>> first, so the user can "step-in" to the inlined function.  This is 
>> particularly notable when you have several nested levels of inlining 
>> starting at the same address, we say the naive thing - that we're in the 
>> innermost function, rather than setting up a set of fake step-in's that 
>> mirror the inline nesting.  If somebody wants to take a whack at fixing that 
>> it would be great.  Shouldn't be too hard.  We need to do other kinds of 
>> fakery as well, for instance if you have three levels of nested inlining and 
>> you set a breakpoint by specifying the middle function, then when you hit 
>> that breakpoint we should pretend we've just stepped into the middle 
>> function.
>> 
>> We handle these fictions with straight-line stepping when it encounters 
>> inlining pretty much okay.  But when we're just running to an address (and 
>> apparently when pushing past the prologue) we're not telling the right story.
>> 
>> Jim
>> 
>>> On Sep 14, 2017, at 3:20 AM, Tamas Berghammer via lldb-dev 
>>>  wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> Thank your for looking into the LLDB failure. I looked into it briefly and 
>>> the issue is that we have have 2 function f and g where g is inlined into f 
>>> as the first call and this causes the first non-prologue line entry of f to 
>>> be inside the address range of g what means that when we step info f from 
>>> outside we will end up inside g instead. Previously the first line entry 
>>> for f matched with the start address of the inlined copy of g where LLDB 
>>> was able to handle the stepping properly.
>>> 
>>> For the concrete example you should compile 
>>> https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp
>>>  with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0 
>>> -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe that 
>>> caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the inlined 
>>> inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the first 
>>> line entry after "Set prologue_end to true" is at 0x8048796 while 
>>> previously it was at 0x8048793.
>>> 
>>> Tamas
>>> 
>>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev 
>>>  wrote:
>>> Hi,
>>> 
>>> I have been working on a compiler issue, where instructions associated to 
>>> the function prolog are assigned line information, causing the debugger to 
>>> show incorrectly the beginning of the function body.
>>> 
>>> For a full description, please see:
>>> 
>>> https://reviews.llvm.org