Hi Zachary,
We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
(Emulator). Most development takes place in Visual Studio, where it builds
as part of the rest of the SwiftShader solution. So we care about LLVM
source files compiling successfully within Visual Studio.
Would
So IIUC this all 1 big solution, one component of which is LLVM? How do you
get them all together in 1 big solution?
On Wed, Oct 10, 2018 at 7:16 AM Nicolas Capens
wrote:
> Hi Zachary,
>
> We use LLVM JIT in SwiftShader, which is used by Google Chrome and Android
> (Emulator). Most development ta
Sorry for being late to the party, I have been away.
I am not persuaded that this patch is functionally correct.
It's lovely to reduce size, but not at the cost of telling
un-truths about source locations of instructions. If the
instructions at the top of the block have no source location,
and yo
If you compile with –ffunction-sections you get one sequence per function. But
DWARF does let you have multiple functions described by one sequence, so you
need to accommodate that. And, the end-prologue flag is an opcode in the
line-number program, so if you're looking for prolog/epilog instr
So I haven't worked much on debug info, but here's the explanation for my
patches:
My original motivation was getting rid of code some code in the llvm codegen
that for spills and reloads just picked the next debug location around. That
just seemed wrong to me, as spills and reloads really are b
> On Oct 10, 2018, at 9:16 AM, Matthias Braun wrote:
>
> So I haven't worked much on debug info, but here's the explanation for my
> patches:
> My original motivation was getting rid of code some code in the llvm codegen
> that for spills and reloads just picked the next debug location around.
> On Oct 10, 2018, at 9:54 AM, Vedant Kumar wrote:
>
>> On Oct 10, 2018, at 9:16 AM, Matthias Braun wrote:
>>
>> So I haven't worked much on debug info, but here's the explanation for my
>> patches:
>> My original motivation was getting rid of code some code in the llvm codegen
>> that for
A couple of additional data points to consider…
Approximately 30% of all reported bugs are still open.
The number of open bugs grows by roughly 28 per week. This has been consistent
for the past 6 years, when I started tracking it. I've reported this to the
mailing list a few times as an FYI.
S
John Reagan at VMS Software has made noises about adopting LLDB, in which case
it would need to support PLI and COBOL types. Looping him in directly.
--paulr
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chirag
Patel via lldb-dev
Sent: Tuesday, October 09, 2018 6:56 AM
To
> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com]
> Sent: Wednesday, October 10, 2018 2:20 PM
> To: Vedant Kumar
> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>
> On Oct 10, 2018, at 12:18 PM, via llvm-commits
> wrote:
>
>
>
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Wednesday, October 10, 2018 2:20 PM
>> To: Vedant Kumar
>> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
>> S
> On Oct 10, 2018, at 12:18 PM, via llvm-commits
> wrote:
>
>
>
>> -Original Message-
>> From: jing...@apple.com [mailto:jing...@apple.com]
>> Sent: Wednesday, October 10, 2018 2:20 PM
>> To: Vedant Kumar
>> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
>> S
> -Original Message-
> From: Matthias Braun [mailto:ma...@braunis.de]
> Sent: Wednesday, October 10, 2018 3:48 PM
> To: Robinson, Paul
> Cc: jing...@apple.com; v...@apple.com; llvm-comm...@lists.llvm.org; lldb-
> d...@lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: P
> -Original Message-
> From: Matthias Braun [mailto:ma...@braunis.de]
> Sent: Wednesday, October 10, 2018 3:50 PM
> To: Robinson, Paul
> Cc: jing...@apple.com; v...@apple.com; llvm-comm...@lists.llvm.org; lldb-
> d...@lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: P
I don't personally use the Xcode generator, but I know lots of people who do.
The Xcode generator can generate a working Xcode project with an accurate clang
index. One of the challenges to get that working though is that the project
actually has to be able to build at least through intrinsics_g
1) So I went and figured out why the lldb testcase at hand fails.
- It seems the debugger stepping logic will follow the program along until it
finds a new source location. However if that new source location is part of a
new DW_AT_abstract_location it is ignored in the step over mode.
- In the
Thanks for looking into this!
When I was first working on inlined stepping, I found a bunch of cases where
the line table info and the ranges for the inlined subroutines disagreed. I
remember seeing cases, for instance, where the address given for foo.h:xxx in
the line table was contained in
Sent from my iPhone
> On Oct 8, 2018, at 8:09 AM, Zachary Turner via llvm-dev
> wrote:
>
>
>
>> On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell wrote:
>> Thanks for raising this.
>>
>> This is a topic I've been interested in for a while too, as I've had to do a
>> few of those lite.site.cfg
18 matches
Mail list logo
