https://llvm.org/bugs/show_bug.cgi?id=28353
Bug ID: 28353
Summary: TestTopLevelExprs.py fails with gcc-4.8
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
P
https://llvm.org/bugs/show_bug.cgi?id=28354
Bug ID: 28354
Summary: TestTemplateIntegerArgs.py fails with gcc
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Hi all,
We have a process that contains multiple definitions of the same
function. The function in question is declared 'static extern' in a
header and included in multiple compilation units.
This causes some confusion for lldb expression parser when trying to
invoke the function by name, sin
Hi Adrien,
I think your diagnosis is correct here. LLDB does indeed create an
additional connection to the gdb-server instance which is started by the
platform instance when you start debugging. In case of android platforms we
already include code to forward this port automatically, but there is n
Hi all,
A short summary: Takumi has done 90% of the work here:
https://github.com/llvm-project/llvm-project-submodule
and I've been talking to GitHub, and here are the answers to my questions:
> 1. How will the umbrella project's auto-increment hook work?
Since the umbrella project cannot see
On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev
wrote:
>
> Any more comments before we put this proposal to vote?
Thank you very much for driving all of this. I just have one quick question:
Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
continue to work by
On 6/29/2016 10:03 AM, Renato Golin via cfe-dev wrote:
> Since the umbrella project cannot see the sub-modules' commits without
> some form of update, there are two ways to do this:
>
> P. Per push: Every push (not commit) on all other repositories will
> trigger a hook that will hit a URL on our s
On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to
Hi all,
Given a file name, line number and variable name, I am trying to determine the
address. I tried the following approach:
* First I got the block corresponding to the file and line:
o from the file name I got a SBCompileUnit
o using the SBCompileUnit and line number I got a S
> On Jun 29, 2016, at 9:51 AM, Bogdan Hopulele via lldb-dev
> wrote:
>
> Hi all,
>
> Given a file name, line number and variable name, I am trying to determine
> the address. I tried the following approach:
> · First I got the block corresponding to the file and line:
> o from the
We have a not-yet-implemented scheme to allow some syntax like:
(lldb) expr $$foo.c$bar(5)
that would mean: look up the version of bar defined in foo.c and call that.
What I wrote above isn't right, since the "." is going to cause the parser
headaches, so we'll have to come up with some clever
Thanks Jim, thats some very helpful information.
Sounds like we should take a closer look at our setup to see why the
existing precedence is having trouble resolving this for us.
Aidan
On 29/06/16 18:24, Jim Ingham wrote:
We have a not-yet-implemented scheme to allow some syntax like:
(lldb)
On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On 27 June 2016 at 17:03, Rafael Espíndola
>> wrote:
>> > I think that trying to create a ordering/
On 29 June 2016 at 15:11, David Chisnall wrote:
> Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
> continue to work by simply switching the remote in the config?
I hope so. There isn't anything (modulo mistakes) stopping us from
having a clean migration.
We'll have
On 29 June 2016 at 16:50, Tom Honermann wrote:
> How would you coordinate dependent updates to the sub-modules?
We won't. Not now. Maybe later.
Right now, doing that means changing how we work and we're trying to
make the least number of changes at a time.
But this is the most requested feature
On 29 June 2016 at 19:51, Sean Silva wrote:
> Roughly speaking, I would prefer a repo division (if any) to be along the
> lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff
> not strictly required".
The problem comes when different people consider "core" different projects
On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin
wrote:
> On 29 June 2016 at 19:51, Sean Silva wrote:
> > Roughly speaking, I would prefer a repo division (if any) to be along the
> > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra
> stuff
> > not strictly required".
>
> The p
On 29 June 2016 at 20:14, Sean Silva wrote:
> Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
> important special case we may be able to agree on. (and I say this as
> somebody that largely builds cross-compilers (targeting PS4))
In that case, RT wouldn't "have" to be cor
On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin
wrote:
> On 29 June 2016 at 20:14, Sean Silva wrote:
> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
> > important special case we may be able to agree on. (and I say this as
> > somebody that largely builds cross-compil
On Wed, Jun 29, 2016 at 12:34 PM, Sean Silva wrote:
>
>
> On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin
> wrote:
>
>> On 29 June 2016 at 20:14, Sean Silva wrote:
>> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
>> > important special case we may be able to agree on
Nevermind, I was finally unable to build by "git pull" and
"xcodebuild -configuration Debug"
On Mon, Jun 27, 2016 at 9:55 PM, Jeffrey Tan
wrote:
> Hi,
>
> I followed instructions in http://lldb.llvm.org/build.html to build lldb
> on Mac.
>
> I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, sele
On Fri, Jun 10, 2016 at 1:38 PM, Hans Wennborg wrote:
> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases
> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev
> wrote:
>
> Hi all,
>
> A short summary: Takumi has done 90% of the work here:
>
> https://github.com/llvm-project/llvm-project-submodule
>
> and I've been talking to GitHub, and here are the answers to my questions:
>
>
>> 1. How
> That makes it fragile, and that’s why I disagree with your “90% done”
> assessment.
> What if the service behing the hook is down for a few days?
In the long-term view, a pretty trivial catch-up script ought to be
able to synthesize a sane history after any amount of down-time.
People could eve
24 matches
Mail list logo
