[lldb-dev] [Bug 24733] RegisterCommandsTestCase.test_fp_special_purpose_register_read fails when inferior is compiled with clang

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24733

abhiinnit...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Difference of behaviour of process.Continue() between MacOSX and Linux

[Louis Granboulan via lldb-dev]

Dear all,

I am new to lldb-dev and I hope that this issue has not already been
reported. I did not find any reference of it.

I started with the example from section "Using the lldb.py module in
python" of
http://lldb.llvm.org/python-reference.html
and decided to have the process continue after having printed some
information about the breakpoint context. It allows to have multiple
breakpoints and display information about every breakpoint, or to have a
breakpoint at a function that is called many times and to display
information for every call.

On a MacOSX machine (any recent version) it works well, but on a Linux
machine (Ubuntu 14.04 64 bits) it looks like process.Continue() makes the
program continue at the breakpoint instead of at the instruction following
the breakpoint. Therefore, it enters an infinite loop.

I can attach the python script, but this script is just made by taking the
example of the webpage, putting in a "while True" loop everything after
"state = process.GetState()" and adding at the end of the loop the
instruction "process.Continue()".

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

Re: [lldb-dev] Difference of behaviour of process.Continue() between MacOSX and Linux

[Pavel Labath via lldb-dev]

Hi,

thanks for your report.

Let me first ask you a question. Which version of lldb are you using?

If it's anything less than 3.7, then I strongly recommend to upgrade,
since linux support was not in a very good state there. If you are
using 3.7 or svn, then the thing you are describing should work. If it
does not please send your script along with your test app (or better
yet, file a bug at  and I will take a look.

cheers,
pl


On 8 September 2015 at 13:29, Louis Granboulan via lldb-dev
 wrote:
> Dear all,
>
> I am new to lldb-dev and I hope that this issue has not already been
> reported. I did not find any reference of it.
>
> I started with the example from section "Using the lldb.py module in python"
> of
> http://lldb.llvm.org/python-reference.html
> and decided to have the process continue after having printed some
> information about the breakpoint context. It allows to have multiple
> breakpoints and display information about every breakpoint, or to have a
> breakpoint at a function that is called many times and to display
> information for every call.
>
> On a MacOSX machine (any recent version) it works well, but on a Linux
> machine (Ubuntu 14.04 64 bits) it looks like process.Continue() makes the
> program continue at the breakpoint instead of at the instruction following
> the breakpoint. Therefore, it enters an infinite loop.
>
> I can attach the python script, but this script is just made by taking the
> example of the webpage, putting in a "while True" loop everything after
> "state = process.GetState()" and adding at the end of the loop the
> instruction "process.Continue()".
>
> Regards,
> Louis
>
> ___
> 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] Difference of behaviour of process.Continue() between MacOSX and Linux

[Louis Granboulan via lldb-dev]

Thank you for your quick answer.
I am using lldb 3.6.0 (the only one packaged for this Ubuntu).
I will see if a more recent Ubuntu has lldb 3.7, or try to install a recent
version from the sources.
Regards,
Louis

On 8 September 2015 at 14:58, Pavel Labath  wrote:

> Hi,
>
> thanks for your report.
>
> Let me first ask you a question. Which version of lldb are you using?
>
> If it's anything less than 3.7, then I strongly recommend to upgrade,
> since linux support was not in a very good state there. If you are
> using 3.7 or svn, then the thing you are describing should work. If it
> does not please send your script along with your test app (or better
> yet, file a bug at  and I will take a look.
>
> cheers,
> pl
>
>
> On 8 September 2015 at 13:29, Louis Granboulan via lldb-dev
>  wrote:
> > Dear all,
> >
> > I am new to lldb-dev and I hope that this issue has not already been
> > reported. I did not find any reference of it.
> >
> > I started with the example from section "Using the lldb.py module in
> python"
> > of
> > http://lldb.llvm.org/python-reference.html
> > and decided to have the process continue after having printed some
> > information about the breakpoint context. It allows to have multiple
> > breakpoints and display information about every breakpoint, or to have a
> > breakpoint at a function that is called many times and to display
> > information for every call.
> >
> > On a MacOSX machine (any recent version) it works well, but on a Linux
> > machine (Ubuntu 14.04 64 bits) it looks like process.Continue() makes the
> > program continue at the breakpoint instead of at the instruction
> following
> > the breakpoint. Therefore, it enters an infinite loop.
> >
> > I can attach the python script, but this script is just made by taking
> the
> > example of the webpage, putting in a "while True" loop everything after
> > "state = process.GetState()" and adding at the end of the loop the
> > instruction "process.Continue()".
> >
> > Regards,
> > Louis
> >
> > ___
> > 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] [Bug 14600] Convenience and exception state registers are not supported on Linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=14600

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from ema...@freebsd.org ---
It looks like this should be resolved by:

r192263 (adding convenience registers on !Darwin platforms)
r234992 (updating test to exclude exception state registers on !Darwin and
removing expectedFailureLinux)
r247009 (removing expectedFailureFreeBSD)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Fwd: Difference of behaviour of process.Continue() between MacOSX and Linux

[Louis Granboulan via lldb-dev]

Oups, I forgot to include the list in the reply to Pavel.
---

No lldb-3.7 in http://llvm.org/apt/trusty/
lldb-3.8 is provided (I guess it is the svn version) and everything seems
OK.
It might be a good idea to mention on http://lldb.llvm.org/ (probably in
the "platform support" paragraph) that the support for Linux is not good
until 3.7.
Regards,
Louis

On 8 September 2015 at 15:04, Louis Granboulan <
louis.granboulan.develo...@gmail.com> wrote:

> Thank you for your quick answer.
> I am using lldb 3.6.0 (the only one packaged for this Ubuntu).
> I will see if a more recent Ubuntu has lldb 3.7, or try to install a
> recent version from the sources.
> Regards,
> Louis
>
> On 8 September 2015 at 14:58, Pavel Labath  wrote:
>
>> Hi,
>>
>> thanks for your report.
>>
>> Let me first ask you a question. Which version of lldb are you using?
>>
>> If it's anything less than 3.7, then I strongly recommend to upgrade,
>> since linux support was not in a very good state there. If you are
>> using 3.7 or svn, then the thing you are describing should work. If it
>> does not please send your script along with your test app (or better
>> yet, file a bug at  and I will take a look.
>>
>> cheers,
>> pl
>>
>>
>> On 8 September 2015 at 13:29, Louis Granboulan via lldb-dev
>>  wrote:
>> > Dear all,
>> >
>> > I am new to lldb-dev and I hope that this issue has not already been
>> > reported. I did not find any reference of it.
>> >
>> > I started with the example from section "Using the lldb.py module in
>> python"
>> > of
>> > http://lldb.llvm.org/python-reference.html
>> > and decided to have the process continue after having printed some
>> > information about the breakpoint context. It allows to have multiple
>> > breakpoints and display information about every breakpoint, or to have a
>> > breakpoint at a function that is called many times and to display
>> > information for every call.
>> >
>> > On a MacOSX machine (any recent version) it works well, but on a Linux
>> > machine (Ubuntu 14.04 64 bits) it looks like process.Continue() makes
>> the
>> > program continue at the breakpoint instead of at the instruction
>> following
>> > the breakpoint. Therefore, it enters an infinite loop.
>> >
>> > I can attach the python script, but this script is just made by taking
>> the
>> > example of the webpage, putting in a "while True" loop everything after
>> > "state = process.GetState()" and adding at the end of the loop the
>> > instruction "process.Continue()".
>> >
>> > Regards,
>> > Louis
>> >
>> > ___
>> > 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] Breakpoints on inlined functions described by DW_AT_ranges

[Jim Ingham via lldb-dev]

Ah, okay.  For a while the llvm-dsymutil folks were trying to make the output 
of dsymutil & llvm-dsymutil identical so that they could be sure llvm-dsymutil 
was doing the right thing, so I'm a little surprised the two differ in this 
regard.  But if it works with .o files & llvm-dsymutil I think that's all we 
really care about at this point.

Jim


> On Sep 4, 2015, at 7:03 PM, Keno Fischer  wrote:
> 
> Actually, it's not a clang bug either. The info is there in the .o file. This 
> only happens if lldb is looking in the .dSYM. If I delete that and let lldb 
> look in the .o files, it sets the breakpoint just fine, so I'll chalk this up 
> as a dsymutil bug. llvm-dsymutil works fine.
> 
> On Fri, Sep 4, 2015 at 9:41 PM, Keno Fischer  
> wrote:
> Hi Jim,
> 
> I tried to work on this, but everything there actually seemed correct. It now 
> seems to me like those functions are simply missing from .apple_names 
> (compiled with latest Clang trunk), so this might not be an LLDB bug after 
> all.
> 
> Keno
> 
> On Fri, Sep 4, 2015 at 3:20 PM, Jim Ingham  wrote:
> Certainly a bug.  This bit:
> 
> if (inlined_die)
> {
> Block &function_block = sc.function->GetBlock (true);
> sc.block = function_block.FindBlockByID (inlined_die.GetID());
> if (sc.block == NULL)
> sc.block = function_block.FindBlockByID 
> (inlined_die.GetOffset());
> if (sc.block == NULL || sc.block->GetStartAddress (addr) == false)
> addr.Clear();
> }
> 
> from SymbolFileDwarf::ResolveFunction is most likely responsible.  I don't 
> remember offhand how the blocks deal with the fact that this one die actually 
> represents multiple blocks, but it's going to be something related to that.
> 
> If you want to have a look, that would be great, otherwise file a bug and we 
> can take a look when we get some free time.
> 
> Jim
> 
> > On Sep 4, 2015, at 12:05 PM, Keno Fischer via lldb-dev 
> >  wrote:
> >
> > I'm trying to set a breakpoint (using `b jl_apply`) on a function 
> > (jl_apply) that is inlined in a number of places. This generally works 
> > fine, but I have noticed that in certain cases LLDB fails to set a 
> > breakpoint even though when I step through manually, it does know which 
> > function the code belongs to. Investigating further, I have found that the 
> > difference comes from whether the inlined subroutine is described via 
> > DW_AT_low_pc or via DW_AT_ranges, so e.g.
> >
> > 0xf6c8:   DW_TAG_inlined_subroutine [42] *
> > DW_AT_abstract_origin [DW_FORM_ref4](cu 
> > + 0x22e7 => {0xd394} "jl_apply")
> > DW_AT_low_pc [DW_FORM_addr] 
> > (0xf768)
> > DW_AT_high_pc [DW_FORM_addr]
> > (0xf776)
> > DW_AT_call_file [DW_FORM_data1] 
> > ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> > DW_AT_call_line [DW_FORM_data1] (34)
> >
> > will get a  breakpoint while
> >
> > 0xf6ee: DW_TAG_inlined_subroutine [53] *
> >   DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 
> > 0x22e7 => {0xd394} "jl_apply")
> >   DW_AT_ranges [DW_FORM_data4]  (0xb790
> >  [0xf785 - 0xf788)
> >  [0xf79c - 0xf7b8))
> >   DW_AT_call_file [DW_FORM_data1]   
> > ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> >   DW_AT_call_line [DW_FORM_data2]   (1668)
> >
> > will not. Is this the intended behavior or a bug? If it's a bug, any ideas 
> > where to look to try to fix it?
> >
> > Thanks,
> > Keno
> > ___
> > 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] Windows build questions

[Ted Woodward via lldb-dev]

Zachary, when you say x64 runtime support isn’t there yet, you mean for VS2015 
and/or Win 10, right? I’ve been building x64 LLDB on Win 7 with VS 2013 for 2 
years now.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Monday, September 07, 2015 3:02 PM
To: Todd Fiala; LLDB; Stephane Sezer
Subject: Re: [lldb-dev] Windows build questions

 

+Stephane because he just went through the pain of getting a working build on 
Windows, so he might be able to point out some gotchas.

 

About VS 2015

VS 2015 does not work because of Python.  Technically, it could theoretically 
work but you won't be able to run the test suite at all.  I don't plan to put a 
significant amount of effort into addressing this.  Instead, this will be 
solved automatically if / when we address http://llvm.org/pr24461.  You can use 
VS 2013 community edition though.  TL;DR of the reason VS 2015 doesn't work is 
because a) Python and the program embedding python must be compiled with the 
same compiler, and b) Python doesn't compile with VS 2015 because it relies on 
implementation details of the CRT, which changed in 2015.

 

About Windows 10

The build shoudl work fine on Windows 10 x64.  That's what I use every day.  
But you should still build an x86 LLDB, not an x64 one.  x64 should work in 
theory (insofar as the build should succeed), but the actual runtime support 
isn't there yet so many things will fail.

 

A couple of things you might run into:

 

1) Make sure PYTHONHOME and PYTHONPATH are not set, otherwise LLDB's python and 
system python can run into conflicts.

 

2) Make sure you check out and build LLD, test executables must be linked with 
LLD or they will not have debug info.  Also, make sure you specify 
LLDB_TEST_COMPILER on the cmake command line to point to a clang.exe (If you 
use a release clang then ninja check-lldb will be faster by an order of 
magnitude)

 

3) Make sure you build Python from source, run the install-custom-python.py, 
and specify -DPYTHON_HOME on the CMake command line.  

 

Most of this is covered on the website build instructions, but I admit it's a 
lot of steps, and it's easy to miss one.  Solving pr24461 should greatly 
simplify everything about building on Windows when I finally get around to it, 
but it's a lot of work.  Still follow the build instructions anyway because 
there's other things as well, but the above 3 are probably the most likely to 
trip you up.

 

On Mon, Sep 7, 2015 at 10:33 AM Todd Fiala via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

Hi all,

 

I've read the Windows lldb build instructions.  I have a few questions just to 
verify before I put too much time into that end:

 

* Has the build been vetted on Windows 10 64-bit yet?

 

* Can Visual Studio 2015 Community Edition work as the compiler toolchain?  (VS 
2012+ is listed as okay, so I'm hoping yes).

 

Thanks!

-- 

-Todd

___
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] Windows build questions

[Zachary Turner via lldb-dev]

Yes, I just mean the debugger can't debug x64 inferiors very well.

On Tue, Sep 8, 2015 at 10:45 AM Ted Woodward 
wrote:

> Zachary, when you say x64 runtime support isn’t there yet, you mean for
> VS2015 and/or Win 10, right? I’ve been building x64 LLDB on Win 7 with VS
> 2013 for 2 years now.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of 
> *Zachary
> Turner via lldb-dev
> *Sent:* Monday, September 07, 2015 3:02 PM
> *To:* Todd Fiala; LLDB; Stephane Sezer
> *Subject:* Re: [lldb-dev] Windows build questions
>
>
>
> +Stephane because he just went through the pain of getting a working build
> on Windows, so he might be able to point out some gotchas.
>
>
>
> *About VS 2015*
>
> VS 2015 does not work because of Python.  Technically, it could
> theoretically work but you won't be able to run the test suite at all.  I
> don't plan to put a significant amount of effort into addressing this.
> Instead, this will be solved automatically if / when we address
> http://llvm.org/pr24461.  You can use VS 2013 community edition though.
> TL;DR of the reason VS 2015 doesn't work is because a) Python and the
> program embedding python must be compiled with the same compiler, and b)
> Python doesn't compile with VS 2015 because it relies on implementation
> details of the CRT, which changed in 2015.
>
>
>
> *About Windows 10*
>
> The build shoudl work fine on Windows 10 x64.  That's what I use every
> day.  But you should still build an x86 LLDB, not an x64 one.  x64 should
> work in theory (insofar as the build should succeed), but the actual
> runtime support isn't there yet so many things will fail.
>
>
>
> A couple of things you might run into:
>
>
>
> 1) Make sure PYTHONHOME and PYTHONPATH are *not* set, otherwise LLDB's
> python and system python can run into conflicts.
>
>
>
> 2) Make sure you check out and build LLD, test executables must be linked
> with LLD or they will not have debug info.  Also, make sure you specify
> LLDB_TEST_COMPILER on the cmake command line to point to a clang.exe (If
> you use a release clang then ninja check-lldb will be faster by an order of
> magnitude)
>
>
>
> 3) Make sure you build Python from source, run the
> install-custom-python.py, and specify -DPYTHON_HOME on the CMake command
> line.
>
>
>
> Most of this is covered on the website build instructions, but I admit
> it's a lot of steps, and it's easy to miss one.  Solving pr24461 should
> greatly simplify everything about building on Windows when I finally get
> around to it, but it's a lot of work.  Still follow the build instructions
> anyway because there's other things as well, but the above 3 are probably
> the most likely to trip you up.
>
>
>
> On Mon, Sep 7, 2015 at 10:33 AM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> I've read the Windows lldb build instructions.  I have a few questions
> just to verify before I put too much time into that end:
>
>
>
> * Has the build been vetted on Windows 10 64-bit yet?
>
>
>
> * Can Visual Studio 2015 Community Edition work as the compiler toolchain?
>  (VS 2012+ is listed as okay, so I'm hoping yes).
>
>
>
> Thanks!
>
> --
>
> -Todd
>
> ___
> 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] Support for smaller types in Scalar class

[Greg Clayton via lldb-dev]

Yes, Scalar used to support the smaller sizes correctly. Revision 245547 
changed Scalar over to use llvm::APInt and llvm::APFloat and it might have 
messed up char/short support. Please do fix Scalar so it can support it. I 
believe llvm::APInt should be able to correctly support this. I will watch for 
your patch.

Greg

> On Sep 7, 2015, at 8:50 AM, Abid, Hafiz via lldb-dev 
>  wrote:
> 
> Adding lldb-dev. I used wrong address for list in the last emails.
> 
>> -Original Message-
>> From: Abid, Hafiz
>> Sent: 07 September 2015 17:07
>> To: Greg Clayton (gclay...@apple.com)
>> Cc: lldb-...@cs.uiuc.edu
>> Subject: Support for smaller types in Scalar class
>> 
>> Hi Greg,
>> I am working on a target with a lot of 16-bit (and 8-bit) registers. So
>> DW_OP_piece is frequently used in the DWARF for handling not only the
>> basic types but also aggregate types. When a Scalar class variable is created
>> for a 16-bit (or 8-bit) data read from the register, it promotes it to int as
>> Scalar class does not have support for short (or char). So in the 
>> calculation of
>> the size of that piece in value::AppendDataToHostBuffer, the scalar instance
>> will return 4 instead of 2 (or 1) from Scalar::GetByteSize(). This messes up 
>> the
>> calculation of piece size and variable evaluation fails.
>> 
>> Adding support of 16-bit (and 8-bit) in Scalar class solve this problem.
>> Although it needs a lot of changes in this class, but most of them are
>> mechanical. If this this approach seems right to you then I will send patches
>> for review.
>> 
>> Thanks,
>> Abid
> 
> ___
> 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] Breakpoints on inlined functions described by DW_AT_ranges

[Greg Clayton via lldb-dev]

If llvm-dsymutil is dropping the name, then send me your example and I will 
file a bug on them to get this fixed.

Greg Clayton

> On Sep 8, 2015, at 10:06 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> Ah, okay.  For a while the llvm-dsymutil folks were trying to make the output 
> of dsymutil & llvm-dsymutil identical so that they could be sure 
> llvm-dsymutil was doing the right thing, so I'm a little surprised the two 
> differ in this regard.  But if it works with .o files & llvm-dsymutil I think 
> that's all we really care about at this point.
> 
> Jim
> 
> 
>> On Sep 4, 2015, at 7:03 PM, Keno Fischer  
>> wrote:
>> 
>> Actually, it's not a clang bug either. The info is there in the .o file. 
>> This only happens if lldb is looking in the .dSYM. If I delete that and let 
>> lldb look in the .o files, it sets the breakpoint just fine, so I'll chalk 
>> this up as a dsymutil bug. llvm-dsymutil works fine.
>> 
>> On Fri, Sep 4, 2015 at 9:41 PM, Keno Fischer  
>> wrote:
>> Hi Jim,
>> 
>> I tried to work on this, but everything there actually seemed correct. It 
>> now seems to me like those functions are simply missing from .apple_names 
>> (compiled with latest Clang trunk), so this might not be an LLDB bug after 
>> all.
>> 
>> Keno
>> 
>> On Fri, Sep 4, 2015 at 3:20 PM, Jim Ingham  wrote:
>> Certainly a bug.  This bit:
>> 
>>if (inlined_die)
>>{
>>Block &function_block = sc.function->GetBlock (true);
>>sc.block = function_block.FindBlockByID (inlined_die.GetID());
>>if (sc.block == NULL)
>>sc.block = function_block.FindBlockByID 
>> (inlined_die.GetOffset());
>>if (sc.block == NULL || sc.block->GetStartAddress (addr) == false)
>>addr.Clear();
>>}
>> 
>> from SymbolFileDwarf::ResolveFunction is most likely responsible.  I don't 
>> remember offhand how the blocks deal with the fact that this one die 
>> actually represents multiple blocks, but it's going to be something related 
>> to that.
>> 
>> If you want to have a look, that would be great, otherwise file a bug and we 
>> can take a look when we get some free time.
>> 
>> Jim
>> 
>>> On Sep 4, 2015, at 12:05 PM, Keno Fischer via lldb-dev 
>>>  wrote:
>>> 
>>> I'm trying to set a breakpoint (using `b jl_apply`) on a function 
>>> (jl_apply) that is inlined in a number of places. This generally works 
>>> fine, but I have noticed that in certain cases LLDB fails to set a 
>>> breakpoint even though when I step through manually, it does know which 
>>> function the code belongs to. Investigating further, I have found that the 
>>> difference comes from whether the inlined subroutine is described via 
>>> DW_AT_low_pc or via DW_AT_ranges, so e.g.
>>> 
>>> 0xf6c8:   DW_TAG_inlined_subroutine [42] *
>>>DW_AT_abstract_origin [DW_FORM_ref4](cu 
>>> + 0x22e7 => {0xd394} "jl_apply")
>>>DW_AT_low_pc [DW_FORM_addr] 
>>> (0xf768)
>>>DW_AT_high_pc [DW_FORM_addr]
>>> (0xf776)
>>>DW_AT_call_file [DW_FORM_data1] 
>>> ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
>>>DW_AT_call_line [DW_FORM_data1] (34)
>>> 
>>> will get a  breakpoint while
>>> 
>>> 0xf6ee: DW_TAG_inlined_subroutine [53] *
>>>  DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 0x22e7 
>>> => {0xd394} "jl_apply")
>>>  DW_AT_ranges [DW_FORM_data4]  (0xb790
>>> [0xf785 - 0xf788)
>>> [0xf79c - 0xf7b8))
>>>  DW_AT_call_file [DW_FORM_data1]   
>>> ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
>>>  DW_AT_call_line [DW_FORM_data2]   (1668)
>>> 
>>> will not. Is this the intended behavior or a bug? If it's a bug, any ideas 
>>> where to look to try to fix it?
>>> 
>>> Thanks,
>>> Keno
>>> ___
>>> 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] [Bug 24750] New: ExprFormattersTestCase::test_with_dwarf encounters Clang assertion failure on FreeBSD

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24750

Bug ID: 24750
   Summary: ExprFormattersTestCase::test_with_dwarf encounters
Clang assertion failure on FreeBSD
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ema...@freebsd.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

At SVN r247024.

While running the TestFormatters.py test case on FreeBSD I see:

python2.7 SBCommandInterpreter(0x801c6ae00)::HandleCommand (command="frame
variable foo1.b.b_ref --show-types", SBCommandReturnObject(0x801c27b80):
Status:  Success Output Message:
(baz &) foo1.b.b_ref = 0x7fffe1a0: {
  (int) h = 27
  (int) k = 29
}
, add_to_history=0) => 2
python2.7 SBCommandReturnObject(0x801c27b80)::GetOutput () => "(baz &)
foo1.b.b_ref = 0x7fffe1a0: {
  (int) h = 27
  (int) k = 29
}
"
runCmd: frame variable foo1.b.b_ref --show-types
output: (baz &) foo1.b.b_ref = 0x7fffe1a0: {
  (int) h = 27
  (int) k = 29
}

python2.7 SBCommandInterpreter(0x801c6ae00)::HandleCommand (command="expression
--show-types -- *(new foo(47))", SBCommandReturnObject(0x801c27b80),
add_to_history=0)
Assertion failed: (!Loc.isInvalid() && "Can't get file characteristic of
invalid loc!"), function getFileCharacteristic, file
../tools/clang/lib/Basic/SourceManager.cpp, line 1406.

[TestFormatters.py FAILED]

with the following backtrace:

(outer) bt
* thread #1: tid = 100593, 0x000805763ffa libc.so.7`thr_kill + 10 at
thr_kill.S:3, stop reason = signal SIGABRT
  * frame #0: 0x000805763ffa libc.so.7`thr_kill + 10 at thr_kill.S:3
frame #1: 0x000805763f66 libc.so.7`__raise(s=) + 38 at
raise.c:51 [opt]
frame #2: 0x000805762759 libc.so.7`abort + 73 at abort.c:65 [opt]
frame #3: 0x0008057445f1 libc.so.7`__assert(func=,
file=, line=, failedexpr=) + 81 at
assert.c:54 [opt]
frame #4: 0x00080246f0a2
liblldb.so.3.8`clang::SourceManager::getFileCharacteristic(clang::SourceLocation)
const + 274
frame #5: 0x000802aa6fb1
liblldb.so.3.8`clang::Sema::BuildCXXNew(clang::SourceRange, bool,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::SourceRange, clang::QualType,
clang::TypeSourceInfo*, clang::Expr*, clang::SourceRange, clang::Expr*, bool) +
2113
frame #6: 0x000802aa667d
liblldb.so.3.8`clang::Sema::ActOnCXXNew(clang::SourceLocation, bool,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::SourceRange, clang::Declarator&, clang::Expr*) +
1501
frame #7: 0x00080283f85b
liblldb.so.3.8`clang::Parser::ParseCXXNewExpression(bool,
clang::SourceLocation) + 3195
frame #8: 0x000802826dcf
liblldb.so.3.8`clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState) + 1839
frame #9: 0x000802823910
liblldb.so.3.8`clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
+ 128
frame #10: 0x00080282c9ec
liblldb.so.3.8`clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&,
bool, bool, clang::OpaquePtr&, clang::SourceLocation&) + 2460
frame #11: 0x000802826bbc
liblldb.so.3.8`clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState) + 1308
frame #12: 0x0008028267fc
liblldb.so.3.8`clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState) + 348
frame #13: 0x000802823910
liblldb.so.3.8`clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
+ 128
frame #14: 0x00080282386e
liblldb.so.3.8`clang::Parser::ParseExpression(clang::Parser::TypeCastState) +
14
frame #15: 0x00080286604e
liblldb.so.3.8`clang::Parser::ParseExprStatement() + 46
frame #16: 0x0008028657c0
liblldb.so.3.8`clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 3296
frame #17: 0x000802864a42
liblldb.so.3.8`clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, bool, clang::SourceLocation*) + 146
frame #18: 0x00080286c6bf
liblldb.so.3.8`clang::Parser::ParseCompoundStatementBody(bool) + 1743
frame #19: 0x00080286cefa
liblldb.so.3.8`clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 186
frame #20: 0x0008027e4af4
liblldb.so.3.8`clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
1972
frame #21: 0x0008027fc1f2
liblldb.so.3.8`clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned
int, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2626
frame #22: 0x0008027e40e0
liblldb.so.3.8`clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::Pa

[lldb-dev] [Bug 24750] ExprFormattersTestCase::test_with_dwarf encounters Clang assertion failure on FreeBSD

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24750

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from ema...@freebsd.org ---


*** This bug has been marked as a duplicate of bug 24691 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev