Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Robinson, Paul via lldb-dev]

Hi Eric & Orlando,

It’s great to see interest in a lot of different aspects of debug info. At the 
same time, I’m concerned about a risk to making the topic so broad that we 
don’t have time to get through all the things people want to get through.  I’m 
thinking there’s a different way to slice the topics, hopefully without much 
overlap, but that will allow a bit more focus.  No doubt a lot of the same 
people would be interested in multiple slices, but by limiting the scope of 
each conversation I’m hoping we’ll get more accomplished.  I daresay a lot of 
people interested in debug-info quality in general might totally tune out a 
DWARF-nerd discussion 
The slicing could be something like this:


  1.  Getting LLVM to do a better job of tracking info internally, so what gets 
emitted in the end is more representative of the original program. This should 
improve the debugging experience by letting the debugger do a better job of 
mapping the executing program to the original source, because the data it works 
with is more accurate/complete.
 *   This is basically about IR/Metadata handling and representation, 
although it might leak into things like the “is_stmt” flag, and doing better 
with “prologue_end,” which are currently handled by AsmPrinter.
 *   Better handling of induction variables, entry-values, variables with 
multiple locations, etc.
  2.  Changes to optimization passes/pipelines and codegen, to avoid borking 
the source-location and value/variable tracking; again this should improve the 
debugging experience by letting the debugger do a better job of mapping the 
executing program back to the original source, because that mapping is simpler.
 *   This is basically about IR/MIR transforms, and is where an Og/O1 kind 
of topic would fit.
 *   Also things like extended lifetimes, limiting code motion/duplication, 
etc.
  3.  Changing the DWARF spec itself to improve the completeness and efficiency 
of the information it contains.  This should improve the debugging experience 
by making the DWARF itself a richer information source, to the extent that it 
can describe more of what happened to the original program; also hopefully any 
efficiency improvements will allow the debugger to be more responsive.
 *   This is obviously about DWARF itself, although to some extent how we 
go about generating it.
 *   Take better advantage of ranges and the .debug_addr table.  dblaikie 
and clayborg have put up ideas about this.
 *   Figure out a way to allow tracking multiple source locations for an 
individual instruction.  Right now we mostly give up and set locations to 
line-0 when this happens.
 *   Understand the competing needs of profiling and debugging consumers, 
and see what might be doable there.  (Although this might be tough enough to be 
its own topic.)
  4.  Debug-info testing/validation.  How do we decide what is “correct”?
 *   What are the tools we have, what are they good/bad at, what’s missing?

I hear that round-tables can be proposed for either ~half hour or ~full hour, 
so with more focused topics we might rather have shorter sessions?

Thanks,
--paulr

From: llvm-dev  On Behalf Of Eric Christopher 
via llvm-dev
Sent: Tuesday, September 22, 2020 2:42 PM
To: Cazalet-Hyams, Orlando ; LLDB Dev 

Cc: llvm-...@lists.llvm.org
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table

+LLDB Dev

I'll sign up. :)

My particular interests are:

- Og (and O1 as Og)
- Correctness testing tools

Past that the rest of your list seems quite specific, but the overall "line 
tables" and "variable locations" are important.

Relatedly we have a number of DWARF committee members in llvm and another 
possible discussion area could be: "what extensions do debug info consumers 
think should happen to make dwarf a better input into debugging".

Thanks.

-eric


On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:
Hi all,

I haven't seen a proposal for an optimised-code debugging experience Round 
Table yet so here goes!
Please let me know if you are interested by emailing me at:

orlando.hy...@sony.com

Below is a non-exhaustive list of possible topics. Feel free to include any 
preferences and
suggestions in your response.

  a. Line tables:
1. Can we fix is_stmt?
2. Is prologue_end reliable?
3. General stepping behaviour/quality.

  b. Variable locations:
1. The state of DW_OP_entry_values in llvm.
2. The state of the instruction-referencing DBG_VALUE work.
3. The state of multi-register DWARF expressions in llvm.
4. The possibility of salvaging out-of-liveness values using the 3 projects 
mentioned above.
5. Floating point debug-info quality in llvm.
6. Loop induction variable locations.

  c. Testing debug-info:
1. Variable correctness testing tools.
2. Location coverage testing 

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

Renato wrote:
> If you want to do the test in Clang all the way to asm, you need to
> make sure the back-end is built. Clang is not always build with all
> back-ends, possibly even none.

This is no different than today. Many tests in Clang require a specific
target to exist. Grep clang/test for "registered-target" for example;
I get 577 hits.  Integration tests (here called "end-to-end" tests)
clearly need to specify their REQUIRES conditions correctly.

> To do that in the back-end, you'd have to rely on Clang being built,
> which is not always true.

A frontend-based test in the backend would be a layering violation.
Nobody is suggesting that.

> Hacking our test infrastructure to test different things when a
> combination of components is built, especially after they start to
> merge after being in a monorepo, will complicate tests and increase
> the likelihood that some tests will never be run by CI and bit rot.

Monorepo isn't the relevant thing.  It's all about the build config.

Any test introduced by any patch today is expected to be run by CI.
This expectation would not be any different for these integration tests.

> On the test-suite, you can guarantee that the whole toolchain is
> available: Front and back end of the compilers, assemblers (if
> necessary), linkers, libraries, etc.
> 
> Writing a small source file per test, as you would in Clang/LLVM,
> running LIT and FileCheck, and *always* running it in the TS would be
> trivial.

I have to say, it's highly unusual for me to make a commit that
does *not* produce blame mail from some bot running lit tests.
Thankfully it's rare to get one that is actually my fault.

I can't remember *ever* getting blame mail related to test-suite.
Do they actually run?  Do they ever catch anything?  Do they ever
send blame mail?  I have to wonder about that.

Mehdi wrote:
> David Greene wrote:
>> Personally, I still find source-to-asm tests to be highly valuable and I
>> don't think we need test-suite for that.  Such tests don't (usually)
>> depend on system libraries (headers may occasionally be an issue but I
>> would argue that the test is too fragile in that case).
>> 
>> So maybe we separate concerns.  Use test-suite to do the kind of
>> system-level testing you've discussed but still allow some tests in a
>> monorepo top-level directory that test across components but don't
>> depend on system configurations.
>> 
>> If people really object to a top-level monorepo test directory I guess
>> they could go into test-suite but that makes it much more cumbersome to
>> run what really should be very simple tests.
>
> The main thing I see that will justify push-back on such test is the
> maintenance: you need to convince everyone that every component in LLVM
> must also maintain (update, fix, etc.) the tests that are in other
> components (clang, flang, other future subproject, etc.). Changing the
> vectorizer in the middle-end may require now to understand the kind of
> update a test written in Fortran (or Haskell?) is checking with some
> Hexagon assembly. This is a non-trivial burden when you compute the
> full matrix of possible frontend and backends.

So how is this different from today?  If I put in a patch that breaks
Hexagon, or compiler-rt, or LLDB, none of which I really understand...
or omg Chrome, which isn't even an LLVM project... it's still my job to 
fix whatever is broken.  If it's some component where I am genuinely
clueless, I'm expected to ask for help.  Integration tests would not be 
any different.  

Flaky or fragile tests that constantly break for no good reason would
need to be replaced or made more robust.  Again this is no different
from any other flaky or fragile test.

I can understand people being worried that because an integration test
depends on more components, it has a wider "surface area" of potential
breakage points.  This, I claim, is exactly the *value* of such tests.
And I see them breaking primarily under two conditions.

1) Something is broken that causes other component-level failures.
   Fixing that component-level problem will likely fix the integration
   test as well; or, the integration test must be fixed the same way
   as the component-level tests.

2) Something is broken that does *not* cause other component-level
   failures.  That's exactly what integration tests are for!  They
   verify *interactions* that are hard or maybe impossible to test in
   a component-level way.

The worry I'm hearing is about a third category:

3) Integration tests fail due to fragility or overly-specific checks.

...which should be addressed in exactly the same way as our overly
fragile or overly specific component-level tests.  Is there some
reason they wouldn't be?

--paulr

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: Tom Stellard 
> Sent: Wednesday, October 16, 2019 3:14 PM
> To: Roman Lebedev 
> Cc: Robinson, Paul ; Shoaib Meenai
> ; Mehdi AMINI ; llvm-
> d...@lists.llvm.org; cfe-dev ; openmp-dev (openmp-
> d...@lists.llvm.org) ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
> On 10/16/2019 12:02 PM, Roman Lebedev wrote:
> > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard 
> wrote:
> >>
> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote:
> >>> +1, please.
> >>>
> >>> Also, putting a tag on the *first* commit in the repo,
> >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*!
> >>>
> >>
> >> Do we need to add a tag or is `git rev-list --count HEAD`
> >> good enough?
> > Ah, interesting, that works too, better than nothing.
> > But to be noted that number is different from the `llvm-svn: <>` for
> > the current commit.
> >
> 
> This is expected.  There were a few commits that were filtered
> out in the SVN to git conversion:
> 
> https://github.com/jyknight/llvm-git-migration/blob/master/llvm-svn2git-
> monorepo.rules

Does the same tactic work for the release branches?  Or are we going to 
see some duplicate count numbers on master and the branches?  That might
be confusing.  (FYI at Sony, for release we count revs since the branch,
so the monotonic numbers on branches are generally small.)
--paulr

> 
> -Tom
> 
> >> -Tom
> > Roman
> >
> >>> Roman.
> >>>
> >>> On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev
> >>>  wrote:
> 
>  +1.  And put it in the email (subject?).  While it’s possible to
> derive a count from a hash manually, better to have it in the email in the
> first place.  You can’t rely on order-of-email-delivery to reflect order-
> of-commit.
> 
>  --paulr
> 
> 
> 
>  From: llvm-dev  On Behalf Of Shoaib
> Meenai via llvm-dev
>  Sent: Wednesday, October 16, 2019 1:42 AM
>  To: tstel...@redhat.com; Mehdi AMINI 
>  Cc: llvm-dev ; cfe-dev  d...@lists.llvm.org>; openmp-dev (openmp-...@lists.llvm.org)  d...@lists.llvm.org>; LLDB Dev 
>  Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week
> 
> 
> 
>  I thought we were just going to count commits on a particular branch
> and use the (branch name, commit count) tuple as our monotonic
> incrementing identifier?
> https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-
> numbers-with-git
> 
> 
> 
> 
> 
>  From: cfe-dev  on behalf of cfe-dev
> 
>  Organization: Red Hat
>  Reply-To: "tstel...@redhat.com" 
>  Date: Tuesday, October 15, 2019 at 10:13 PM
>  To: Mehdi AMINI 
>  Cc: llvm-dev , cfe-dev  d...@lists.llvm.org>, "openmp-dev (openmp-...@lists.llvm.org)"  d...@lists.llvm.org>, LLDB Dev 
>  Subject: Re: [cfe-dev] Mailing list changes this week
> 
> 
> 
>  On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
>  On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard  > wrote:
> 
>   On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> 
>   > Hi Tom.
> 
>   >
> 
>   > One issue with this is that we don't have a clear "ordering"
> from linear revision numbers from these emails. Have we looked into
> continuing to generate our own emails per commits instead so that we
> control the format?
> 
>   >
> 
>   This actually what we are doing, we are listening for github
> commit events and
> 
>   then generating our own emails based on the data in the event.
> We can format
> 
>   the emails how ever we want, and we tried to match the current
> SVN format exactly.
> 
>  Ah great!
> 
> 
> 
>   Is the some other information you would like to have in the
> emails to show the
> 
>   ordering?
> 
>  The only thing I was looking to get was to continue to have a
> monotonic incrementing integer for the revision instead of the git hash
> alone: I don't know if `git llvm` has this feature yet but this was
> discussed a while ago (I don't remember if we just mentioned counting the
> commits in the repo from the beginning or using an invocation of `git
> describe` or something derived).
> 
> 
> 
>  We talked about using `git describe` for this, but this would require
> that we
> 
>  add tags to the master branch each time the version number was
> bumped.  We
> 
>  discussed this[1] last year, but deferred the decision, since we
> couldn't get
> 
>  consensus on the tag name.
> 
> 
> 
>  -Tom
> 
> 
> 
>  [1] https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-
> 2DDecember_128484.html=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQX
> KeTWOMw=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ=p_75z-
> WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg=
> 
> 
> 
> 

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Robinson, Paul via lldb-dev]

+1.  And put it in the email (subject?).  While it’s possible to derive a count 
from a hash manually, better to have it in the email in the first place.  You 
can’t rely on order-of-email-delivery to reflect order-of-commit.
--paulr

From: llvm-dev  On Behalf Of Shoaib Meenai via 
llvm-dev
Sent: Wednesday, October 16, 2019 1:42 AM
To: tstel...@redhat.com; Mehdi AMINI 
Cc: llvm-dev ; cfe-dev ; 
openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 

Subject: Re: [llvm-dev] [cfe-dev] Mailing list changes this week

I thought we were just going to count commits on a particular branch and use 
the (branch name, commit count) tuple as our monotonic incrementing identifier? 
https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git


From: cfe-dev 
mailto:cfe-dev-boun...@lists.llvm.org>> on 
behalf of cfe-dev mailto:cfe-...@lists.llvm.org>>
Organization: Red Hat
Reply-To: "tstel...@redhat.com" 
mailto:tstel...@redhat.com>>
Date: Tuesday, October 15, 2019 at 10:13 PM
To: Mehdi AMINI mailto:joker@gmail.com>>
Cc: llvm-dev mailto:llvm-...@lists.llvm.org>>, cfe-dev 
mailto:cfe-...@lists.llvm.org>>, "openmp-dev 
(openmp-...@lists.llvm.org)" 
mailto:openmp-...@lists.llvm.org>>, LLDB Dev 
mailto:lldb-dev@lists.llvm.org>>
Subject: Re: [cfe-dev] Mailing list changes this week

On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard 
mailto:tstel...@redhat.com> 
> wrote:
 On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
 > Hi Tom.
 >
 > One issue with this is that we don't have a clear "ordering" from linear 
revision numbers from these emails. Have we looked into continuing to generate 
our own emails per commits instead so that we control the format?
 >
 This actually what we are doing, we are listening for github commit events 
and
 then generating our own emails based on the data in the event.  We can 
format
 the emails how ever we want, and we tried to match the current SVN format 
exactly.
Ah great!

 Is the some other information you would like to have in the emails to show 
the
 ordering?
The only thing I was looking to get was to continue to have a monotonic 
incrementing integer for the revision instead of the git hash alone: I don't 
know if `git llvm` has this feature yet but this was discussed a while ago (I 
don't remember if we just mentioned counting the commits in the repo from the 
beginning or using an invocation of `git describe` or something derived).

We talked about using `git describe` for this, but this would require that we
add tags to the master branch each time the version number was bumped.  We
discussed this[1] last year, but deferred the decision, since we couldn't get
consensus on the tag name.

-Tom

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2018-2DDecember_128484.html=DwIGaQ=5VD0RTtNlTh3ycd41b3MUw=o3kDXzdBUE3ljQXKeTWOMw=_SmpuqSzuAhMoF3exJmWRp6KnerIOE6WdU4kcv3tjhQ=p_75z-WV3dFcBRoqs2YeTexKxeCf8oyS-atIo6wG6Fg=

--
Mehdi

 -Tom
 > Thanks,
 >
 > --
 > Mehdi
 >
 >
 >
 > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
mailto:cfe-...@lists.llvm.org> 
 >> wrote:
 >
 > Hi,
 >
 > We are going to start to switching from SVN commit emails to GitHub 
commit
 > emails this week.  The only real change you should notice is that
 > the revision number in the subject will be replaced with a git hash 
and
 > the diff links in the email will point to GitHub.  Otherwise the
 > content and format of the email should be the same.
 >
 > We are going to start by rolling this out for the openmp-commits list
 > and then once that's working begin migrating the rest of the lists.  
If you
 > notice any issues with the new emails, please file a bug and mark it
 > as a blocker of the github meta-bug (llvm.org/PR39393 
 
).
 >
 > Thanks,
 > Tom
 > ___
 > cfe-dev mailing list
 > cfe-...@lists.llvm.org 
 >
 > 

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev  On Behalf Of Renato Golin
> via cfe-dev
> Sent: Friday, October 11, 2019 11:24 AM
> To: David Greene 
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; Gerolf Hoflehner
> ; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [cfe-dev] [llvm-dev] RFC: End-to-end testing
> 
> Hi David,
> 
> You answer some of your own questions down below, so I'll try to
> collate the responses and shorten my reply.
> 
> On Fri, 11 Oct 2019 at 15:20, David Greene  wrote:
> > How are regressions reported?  On llvm-dev?
> 
> They're buildbots, exactly like any other. Direct email, llvm-commits,
> irc, bugzilla. There is no distinction, broken bots need to be fixed.
> 
> llvm-dev is not the place to report bugs.
> 
> > I'm confused.  On the one hand you say you don't want to put e2e tests
> > in a dark corner, but here you speculate they could be easily removed.
> > Presumably a test was added because there was some failure that other
> > tests did not catch.  It's true that once a test is fixed it's very
> > likely it will never break again.  Is that a reason to remove tests?
> 
> Sorry, my point is about the dynamics between number of tests, their
> coverage, time to run, frequency of *unrelated* breakage, etc.
> 
> There are no set rules, but there is a back-pressure as developers and
> bot owners tend to breakages.
> 
> > What do you mean by "annoy?"  Taking too long to run?
> 
> Tests that break more often are looked at more often, and if their
> breakages overlap with other simpler tests, than developers will begin
> to question their importance. Tests that take too long to run will be
> looked into, and if they don't add much, they can be asked for
> removal. That pressure is higher in the LIT side than in the
> test-suite.
> 
> I'm trying to find a place where we can put the tests that will run at
> the appropriate frequency and have the lowest probability of upsetting
> CI and developers, so we can evolve them into what they *need* to be,
> not cap it from the start and end up with something sub-par.
> 
> > Would it be possible to keep them in the monorepo but have bots that
> > exercise those tests at the test-suite frequency?  I suspect that if e2e
> > tests live in test-suite very few people will ever run them before
> > merging to master.
> 
> Bots are pretty dumb: either they run something or they don't.
> 
> But more importantly, if we split the e2e tests in LIT, then people
> won't run them before merging to master anyway.

Depends on whether they are part of check-all.

> Truth is, we don't *need* to. That's the whole point of having a fast
> CI and the community really respects that.
> 
> As long as we have the tests running every few dozen commits, and bot
> owner and developers work to fix them in time, we're good.
> 
> Furthermore, the test-suite already has e2e tests in there, so it is
> the right place to add more. We can have more control of which tools
> and libraries to use, how to check for quality, etc.

My understanding is that test-suite had large-ish executable tests.
David is talking about small compile-only e2e tests.  These would hardly
take any more time than any other existing lit test.

> > I still think the kinds of e2e tests I'm thinking of are much closer to
> > the existing LIT tests in the monorepo than things in test-suite.  I
> > expect them to be quite small.
> 
> Adding tests to LIT means all fast bots will be slower. Adding them to
> the test-suite means all test-suite bots will still take the about
> same time.
> 
> If the tests only need to be ran once ever few dozen commits, then
> having them on LIT is clearly not the right place.

The lit-versus-test-suite distinction is not the right one.  Bots don't
run "lit tests" as one big lump; they run the tests for a configured set
of projects.  If the e2e tests are in with all the other clang tests, 
then they get run by the clang bots.  If they are in a different project 
(test-suite or their own) then they get run by the bots that run that 
project.  This is decided by the bot owner.

> 
> > They wouldn't necessarily need to run as
> > part of check-all (and indeed, I've been told that no one runs check-all
> > anyway because it's too fragile).
> 
> check-all doesn't need to check everything that is in the repo, but
> everything that is built.
> 
> So if you build llvm+clang, then you should *definitely* check both.
> "make check" doesn't do that.
> 
> With the monorepo this may change slightly, but we still need a way to
> test everything that our patches touch, including clang, rt, and
> others.
> 
> I always ran check-all before every patch, FWIW.

Yep.  Although I run check-all before *starting* on a patch, to make sure
the starting point is clean.  It usually is, but I've been caught enough
times to be slightly wary.
--paulr

> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> 

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

David Greene, will you be at the LLVM Dev Meeting? If so, could you sign
up for a Round Table session on this topic?  Obviously lots to discuss
and concerns to be addressed.

In particular I think there are two broad categories of tests that would
have to be segregated just by the nature of their requirements:

(1) Executable tests. These obviously require an execution platform; for
feasibility reasons this means host==target and the guarantee of having
a linker (possibly but not necessarily LLD) and a runtime (possibly but
not necessarily including libcxx).  Note that the LLDB tests and the 
debuginfo-tests project already have this kind of dependency, and in the
case of debuginfo-tests, this is exactly why it's a separate project.

(2) Non-executable tests.  These are near-identical in character to the
existing clang/llvm test suites and I'd expect lit to drive them.  The 
only material difference from the majority(*) of existing clang tests is 
that they are free to depend on LLVM features/passes.  The only difference 
from the majority of existing LLVM tests is that they have [Obj]{C,C++} as 
their input source language.
(*) I've encountered clang tests that I feel depend on too much within LLVM,
and it's common for new contributors to provide a C/C++ test that needs to 
be converted to a .ll test.  Some of them go in anyway.

More comments/notes below.

> -Original Message-
> From: lldb-dev  On Behalf Of David Greene
> via lldb-dev
> Sent: Wednesday, October 09, 2019 9:25 PM
> To: Philip Reames ; llvm-...@lists.llvm.org;
> cfe-...@lists.llvm.org; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing
> 
> Philip Reames via cfe-dev  writes:
> 
> > A challenge we already have - as in, I've broken these tests and had to
> > fix them - is that an end to end test which checks either IR or assembly
> > ends up being extraordinarily fragile.  Completely unrelated profitable
> > transforms create small differences which cause spurious test failures.
> > This is a very real issue today with the few end-to-end clang tests we
> > have, and I am extremely hesitant to expand those tests without giving
> > this workflow problem serious thought.  If we don't, this could bring
> > development on middle end transforms to a complete stop.  (Not kidding.)
> 
> Do you have a pointer to these tests?  We literally have tens of
> thousands of end-to-end tests downstream and while some are fragile, the
> vast majority are not.  A test that, for example, checks the entire
> generated asm for a match is indeed very fragile.  A test that checks
> whether a specific instruction/mnemonic was emitted is generally not, at
> least in my experience.  End-to-end tests require some care in
> construction.  I don't think update_llc_test_checks.py-type operation is
> desirable.

Sony likewise has a rather large corpus of end-to-end tests.  I expect any
vendor would.  When they break, we fix them or report/fix the compiler bug.
It has not been an intolerable burden on us, and I daresay if it were at
all feasible to put these upstream, it would not be an intolerable burden
on the community.  (It's not feasible because host!=target and we'd need
to provide test kits to the community and our remote-execution tools. We'd
rather just run them internally.)

Philip, what I'm actually hearing from your statement is along the lines,
"Our end-to-end tests are really fragile, therefore any end-to-end test 
will be fragile, and that will be an intolerable burden."

That's an understandable reaction, but I think the community literally
would not tolerate too-fragile tests.  Tests that are too fragile will 
be made more robust or removed.  This has been community practice for a 
long time.  There's even an entire category of "noisy bots" that certain 
people take care of and don't bother the rest of the community.  The 
LLVM Project as a whole would not tolerate a test suite that "could 
bring development ... to a complete stop" and I hope we can ease your
concerns.

More comments/notes/opinions below.

> 
> Still, you raise a valid point and I think present some good options
> below.
> 
> > A couple of approaches we could consider:
> >
> >  1. Simply restrict end to end tests to crash/assert cases.  (i.e. no
> > property of the generated code is checked, other than that it is
> > generated)  This isn't as restrictive as it sounds when combined
> > w/coverage guided fuzzer corpuses.
> 
> I would be pretty hesitant to do this but I'd like to hear more about
> how you see this working with coverage/fuzzing.

I think this is way too restrictive.

> 
> >  2. Auto-update all diffs, but report them to a human user for
> > inspection.  This ends up meaning that tests never "fail" per se,
> > but that individuals who have expressed interest in particular tests
> > get an automated notification and a chance to respond on list with a
> > reduced example.
> 
> 

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev  On Behalf Of David Greene
> via llvm-dev
> Sent: Wednesday, October 09, 2019 9:17 PM
> To: Mehdi AMINI 
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; openmp-
> d...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] RFC: End-to-end testing
> 
> Mehdi AMINI via cfe-dev  writes:
> 
> > I don't think these particular tests are the most controversial though,
> and
> > it is really still fairly "focused" testing. I'm much more curious about
> > larger end-to-end scope: for instance since you mention debug info and
> > LLDB, what about a test that would verify that LLDB can print a
> particular
> > variable content from a test that would come as a source program for
> > instance. Such test are valuable in the absolute, it isn't clear to me
> that
> > we could in practice block any commit that would break such test though:
> > this is because a bug fix or an improvement in one of the pass may be
> > perfectly correct in isolation but make the test fail by exposing a bug
> > where we are already losing some debug info precision in a totally
> > unrelated part of the codebase.
> > I wonder how you see this managed in practice: would you gate any change
> on
> > InstCombine (or other mid-level pass) on not regressing any of the
> > debug-info quality test on any of the backend, and from any frontend
> (not
> > only clang)? Or worse: a middle-end change that would end-up with a
> > slightly different Dwarf construct on this particular test, which would
> > trip LLDB but not GDB (basically expose a bug in LLDB). Should we
> require
> > the contributor of inst-combine to debug LLDB and fix it first?
> 
> Good questions!  I think for situations like this I would tend toward
> allowing the change and the test would alert us that something else is
> wrong.  At that point it's probably a case-by-case decision.  Maybe we
> XFAIL the test.  Maybe the fix is easy enough that we just do it and the
> test starts passing again.  What's the policy for breaking current tests
> when the change itself is fine but exposes a problem elsewhere (adding
> an assert, for example)?

For debug info in particular, we already have the debuginfo-tests project,
which is separate because it requires executing the test program; this is
something the clang/llvm test suites specifically do NOT require.  There
is of course also the LLDB test suite, which I believe can be configured
to use the just-built clang to compile its test programs.

Regarding breakage policy, it's just like anything else: do what's needed
to make the bots happy.  What exactly that means will depend on the exact
situation.  I can cite a small patch that was held off for a ridiculously
long time, like around a year, because Chromium had some environmental
problem that they were slow to address.  That wasn't even an LLVM bot!
But eventually it got sorted out and our patch went in.

My point here is, that kind of thing happens already, adding a new e2e
test project won't inherently change any policy or how the community
responds to breakage.
--paulr

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

Re: [lldb-dev] Adding DWARF5 accelerator table support to llvm

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Wednesday, January 17, 2018 8:14 AM
> To: jdevliegh...@apple.com; LLVM Dev; LLDB; David Blaikie; Robinson, Paul
> Subject: Adding DWARF5 accelerator table support to llvm
> 
> Hello all,
> 
> In  it was brought up that
> there are at least two parties interested in having DWARF5 accelerator
> tables implemented, so I'm writing this email to see if there's anyone
> else interested in this topic, and to try to synchronize our efforts.
> 
> Our interest for this stems from a desire to make dwarf parsing fast
> on non-apple targets (specifically android). As you may know, apple
> targets already use a non-standard accelerator table format, which was
> a precursor to the dwarf5 one. Due to other differences in debug info
> deployment model, the apple tables are not directly applicable to
> other targets, so instead of trying to make them fit, we chose to go
> with the standard approach.
> 
> I personally will have some time to work on this this quarter or two,
> and my plan is roughly the following:
> 1. add .debug_names support to llvm-dwarfdump via the DebugInfo
> library (to enable testing of the table generation)
> 2. add .debug_names generation support (not enabled by default)
> 3. add .debug_names support to lldb
> 4. validate all three things work together
> 5. hook up .debug_names to clang's -glldb flag.
> 6. add .debug_names support to lld (accelerator table merging)
> 
> Right now I have (1) roughly implemented, and I think I'll be able to
> put it up for review in a couple of days (although I expect the review
> will go through several revisions before being accepted). I also have
> a very basic implementation of (2), but this is still quite far from
> being upstreamable.
> 
> So, my question is whether anyone is planning to work, or maybe
> working already on dwarf5 accelerator tables? Help with reviewing
> patches would also be greatly appreciated. If you have any questions
> or concerns, let me know.

Hi Pavel,
This would not interfere/duplicate anything Sony is doing in the near
future.  I think having the accelerator tables available for our
debugger team to play with would be nice, and I will certainly try to
spend some time on reviews.

FTR, next thing on the Sony list will be the new range-list/loc-list
format.  We're really hoping to make `-gdwarf-5` a viable thing for
debuggers to try out by LLVM 7.0.  It won't have "everything" but the
basic set of sections should be in place and be syntactically correct.

Thanks,
--paulr

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

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

[Robinson, Paul via lldb-dev]

The linkage-name attribute was really intended for definitions of objects that 
have static memory addresses (static/global variables, and functions), but 
adding it to a class description would have an obvious meaning and seems 
completely in line with how DWARF works.
Given the size of mangled names, you probably want to do this only for 
definitions of classes that have vtables.  With that caveat, I'd have no 
problem doing this.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Tamas 
Berghammer via lldb-dev
Sent: Monday, December 18, 2017 12:00 PM
To: xgsa
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of 
type names inequality in DWARF and mangled symbols


Hi Anton and Jim,

What do you think about storing the mangled type name or the mangled vtable 
symbol name somewhere in DWARF in the DW_AT_MIPS_linkage_name attribute? We are 
already doing it for the mangled names of functions so extending it to types 
shouldn't be too controversial.

Tamas

On Mon, 18 Dec 2017, 17:29 xgsa via lldb-dev, 
> wrote:
Thank you for clarification, Jim, you are right, I misunderstood a little bit 
what lldb actually does.

It is not that the compiler can't be fixed, it's about the fact that relying on 
correspondence of mangled and demangled forms are not reliable enough, so we 
are looking for more robust alternatives. Moreover, I am not sure that such 
fuzzy matching could be done just basing on class name, so it will require 
reading more DIEs. Taking into account that, for instance, in our project there 
are quite many such types, it could noticeable slow down the debugger.

Thus, I'd like to mention one more alternative and get your feedback, if 
possible. Actually, what is necessary is the correspondence of mangled and 
demangled vtable symbol. Possibly, it worth preparing a separate section during 
compilation (like e.g. apple_types), which would store this correspondence? It 
will work fast and be more reliable than the current approach, but certainly, 
will increase debug info size (however, cannot estimate which exact increase 
will be, e.g. in persent).

What do you think? Which solution is preferable?

Thanks,
Anton.

15.12.2017, 23:34, "Jim Ingham" >:
> First off, just a technical point. lldb doesn't use RTTI to find dynamic 
> types, and in fact works for projects like lldb & clang that turn off RTTI. 
> It just uses the fact that the vtable symbol for an object demangles to:
>
> vtable for CLASSNAME
>
> That's not terribly important, but I just wanted to make sure people didn't 
> think lldb was doing something fancy with RTTI... Note, gdb does (or at least 
> used to do) dynamic detection the same way.
>
> If the compiler can't be fixed, then it seems like your solution [2] is what 
> we'll have to try.
>
> As it works now, we get the CLASSNAME from the vtable symbol and look it up 
> in the the list of types. That is pretty quick because the type names are 
> indexed, so we can find it with a quick search in the index. Changing this 
> over to a method where we do some additional string matching rather than just 
> using the table's hashing is going to be a fair bit slower because you have 
> to run over EVERY type name. But this might not be that bad. You would first 
> look it up by exact CLASSNAME and only fall back on your fuzzy match if this 
> fails, so most dynamic type lookups won't see any slowdown. And if you know 
> the cases where you get into this problem you can probably further restrict 
> when you need to do this work so you don't suffer this penalty for every 
> lookup where we don't have debug info for the dynamic type. And you could 
> keep a side-table of mangled-name -> DWARF name, and maybe a black-list for 
> unfound names, so you only have to do this once.
>
> This estimation is based on the assumption that you can do your work just on 
> the type names, without having to get more type information out of the DWARF 
> for each candidate match. A solution that relies on realizing every class in 
> lldb so you can get more information out of the type information to help with 
> the match will defeat all our attempts at lazy DWARF reading. This can cause 
> quite long delays in big programs. So I would be much more worried about a 
> solution that requires this kind of work. Again, if you can reject most 
> potential candidates by looking at the name, and only have to realize a few 
> likely types, the approach might not be that slow.
>
> Jim
>
>>  On Dec 15, 2017, at 7:11 AM, xgsa via lldb-dev 
>> > wrote:
>>
>>  Sorry, I probably shouldn't have used HTML for that message. Converted to 
>> plain text.
>>
>>   Original message 
>>  15.12.2017, 18:01, "xgsa" >:
>>
>>  Hi,
>>
>>  I am working on 

Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the release

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans
> Wennborg via lldb-dev
> Sent: Friday, December 15, 2017 10:07 AM
> To: Chandler Carruth
> Cc: llvm-dev; Release-testers; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev
> Subject: Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the
> release
> 
> On Thu, Dec 14, 2017 at 10:42 PM, Chandler Carruth 
> wrote:
> > FWIW, I don't have really strong objections, but I'm honestly not a fan.
> The
> > reason is mostly that I think it is very late to make the change and
> likely
> > to mean most people are on holiday when the branch occurs. I somewhat
> > anticipate significantly more cherrypicks as a consequence. I'd love for
> > Apple's releases to by sync'd with the open source ones, but I don't
> > understand why one week earlier is so critical. That said, I generally
> defer
> > to those who are working more heavily on the open source releases.
> 
> Thanks for your input. I'm not too worried given that the idea is to
> start slowly and ramp up testing with RC1 which will happen around the
> time it normally would. Let's see how it goes.
> 
> 
> > The one thing I have a stronger opinion about is the idea of a "feature
> > freeze", stabilization period, or other change. I'm pretty strongly
> opposed
> > to this. One of the things that I most appreciate about the LLVM
> community
> > and process is that the top-of-tree is always open, always active, and
> > always kept green.
> 
> I agree. Releases should happen on a branch and not obstruct
> development on trunk (besides the common courtesy of not landing
> majorly disruptive changes righ before the branch as you mentioned
> below). I'm not suggesting any changes here.

FTR it's majorly disruptive changes right *after* the branch that
cause the most headaches for cherry-picking fixes.
--paulr

> 
> 
> > On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev
> >  wrote:
> >>
> >> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg 
> wrote:
> >> > Hello everyone,
> >> >
> >> > It's time to start making plans for the 6.0.0 release.
> >> >
> >> > Following our regular schedule, the branch would occur about two
> weeks
> >> > into January, on Wednesday 17 January 2018, with the goal of shipping
> >> > early March. This is the schedule I would propose.
> >> >
> >> > However, one large consumer of the branch has asked if we could start
> >> > earlier this time, branching on 3 January instead (not moving the
> ship
> >> > date), to get a longer period for stabilization that syncs with their
> >> > internal process.
> >> >
> >> > While I'm hesitant to change the schedule because I think it's
> >> > important that it's predictable, there is a benefit of having large
> >> > users "in sync" with the upstream release branch, as that means more
> >> > people testing the same code.
> >> >
> >> > I will be out of the office the first weeks of January (and I'm
> >> > guessing other members of the community might be too), so while I
> >> > could get the branch started on the 3rd, it would be a kind of
> >> > "slow-start" of the process, but still allow those who want to start
> >> > testing and nominating merges to do so.
> >> >
> >> > Ultimately, it comes down to what the community prefers. Should we
> >> > stick to the regular schedule, or should we do the "slow-start" two
> >> > weeks early this time?
> >> >
> >> > Let me know what you think, especially those of you involved in the
> >> > release testing.
> >>
> >> Since there wasn't really any opposition to the 3 January "slow start"
> >> suggestion, let's go with that. I propose the following schedule:
> >>
> >> 3 January 2018 - Branch point. Those who want can start testing and
> >> nominating merges.
> >> 17 January 2018 - Release Candidate 1 tag, testing of that starts.
> >> 7 February 2018 - Release Candidate 2, things should ideally look
> >> pretty good now
> >> 21 February 2018 - Final tag. (Typically this slips a bit; just try
> >> not to slip into March.)
> >>
> >> Unless there are any objections, I'll post this on the web page soon.
> >>
> >> Cheers,
> >> Hans
> >> ___
> >> Openmp-dev mailing list
> >> openmp-...@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-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] [llvm-dev] [6.0.0 Release] Scheduling the release

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: Renato Golin [mailto:renato.go...@linaro.org]
> Sent: Thursday, December 07, 2017 11:52 AM
> To: Robinson, Paul
> Cc: Hans Wennborg; Release-testers; llvm-dev; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev (lldb-dev@lists.llvm.org)
> Subject: Re: [llvm-dev] [lldb-dev] [6.0.0 Release] Scheduling the release
> 
> On 6 December 2017 at 21:06, Robinson, Paul via llvm-dev
>  wrote:
> > I'm very sympathetic to syncing upstream stabilization with internal
> > processes; that said, branching so soon after New Year's Day (which
> > I'd guess is celebrated essentially everywhere) seems like not such a
> > great idea.  This is not a strong objection, more of an observation.
> 
> Hi Paul,
> 
> I'm curious as to what problems you're expecting... My reasoning (more
> of a feeling) is that most people will refrain from controversial
> changes just before the turn of the year, though I have no data points
> to corroborate that. :)

I agree with you about lower levels of project activity at that point; my
own selfish concern is about internal staffing levels for handling the new
branch, on what for us is the first day back from the holidays.  But as I
said it's not a strong objection, we can make sure to capture the branch
at the correct revision even if we don't do it exactly in the moment, and 
you make a reasonable argument for going with the earlier date.  I don't 
want to stand in the way here.
Thanks,
--paulr

> 
> cheers,
> --renato

___
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

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chris
> Quenelle via lldb-dev
> Sent: Friday, September 22, 2017 4:03 PM
> To: Jim Ingham
> Cc: LLDB
> Subject: Re: [lldb-dev] Prologue instructions having line information
> 
> 
> > On Sep 14, 2017, at 3:32 PM, Jim Ingham  wrote:
> >
> > 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.
> >
> 
> Sorry for the delay in responding.
> 
> For now, I don’t have anything interesting to say about how
> lldb keeps track of which logical function it’s in when
> a single instruction maps to multiple functions.  Jim’s comments
> seem logical.  For all the places in lldb that convert an
> instruction location into a function those would be places to look
> at the code and think about doing something more fancy.
> 
> I did have some thoughts on the range list encoding.
> 
> What follows is not a recommendation, it's just random
> musings.
> 
> range lists...
> They seem to take up more space than they need to.
> 
> So for a single inline instance you need: (assuming 64
> bits obviously)
> 
> 2x64 base address
> 2x64 end of list
> 
> Plus 2x64 for every continuous block of instructions.
> Assuming the usual case of inlining is mixed with
> code scheduling and other optimizations, a single
> inlined instance is likely to be split up pretty
> thoroughly. (This is all logical guesses, I haven't
> gathered any statistics.)
> 
> So if you've got 10 instruction split into 5 chunks
> then you need (1+5+1) * (64*2) which is 112 bytes.
> 
> Since most inlined functions are very small
> the overhead of 4 address words just to open
> up a range list seems pretty inefficient.
> 
> You're effectively painting a boolean property
> on a subset of the instructions in a function.
> With one property per inlined instance.
> 
> In the old Sun days we had a desire to do this
> for a couple of different kinds of information so
> we invested in a fairly concise way to record it.
> 
> We just made a sorted list of the instruction offsets
> from the start of the containing function.  Then encoded
> the sorted list of numbers differentially and stored
> it as a list of ULEBs in a raw data block attribute attached
> to a die that describes the property we're describing.
> It was used for describing ctor and dtor code blocks
> among other things.
> 
> So if you have these function offsets of instructions:
> 
> 1001 1002 1005 1010 1030
> 
> You end up with a list of LEBs like:
> 
> 1001 1 3 5 20(the last 4 numbers are the
>   differences between adjacent pairs)
> 
> And and since LEBs are fairly short when they are small
> it doesn't take much space.  So for this example I think
> it would be just 6 bytes.
> 
> If you had 10 instructions like I used above, then
> you'd have 10 bytes plus a few extra bytes for the
> larger offsets.
> 
> It's much shorter if you can do without address-sized
> fields, and it's easier on the linker to avoid
> lots of relocations.  But the down side is that
> using relocations and offsets allows you to generate
> the section data using assembly syntax without teaching
> your assembler how to generate special dwarf data.
> So that may be why dwarf has relied a little too heavily on
> addresses and relocations for some things.  But that's
> just guess.

For contiguous ranges described by low_pc/hi_pc attribute
pairs, the hi_pc can be a constant for the length, so you save
a little space and a relocation.  I think that’s in DWARF 4.

DWARF 5 redid the ranges section, to do a lot more with ULEBs
and offsets from base addresses.  So it should be a lot more 
compact.  That requires producers to speak DWARF 5, of course; 
I'm trying to make time to do that for Clang.
--paulr

> 
> 
> Now I noticed there was an issue that Paul Robinson
> mentioned on the intertubes where lldb prefers
> fixed-size dies.  The solution in the Studio compilers
> puts the data block inside the die, but it works
> just as well to factor the data out into a different
> section the same way range lists work. It's a little
> less space efficient because of the address pointing
> at the external section, but still better than range lists.
> 
> 
> 
> 
> 
> ___
> 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

[Robinson, Paul via lldb-dev]

The DWARF line table hasn't fundamentally changed since DWARF 2, and
the model is that each instruction maps to one source location (or to
"line 0" for no specific source location).  While it is technically
possible for the _encoding_ of the line table to express more than
one source location for a given instruction, it's not intentional,
AFAICT, and I doubt any consumer is looking for that.

I believe there are proposals floating around to make this better
but that would be part of DWARF 6, whenever it comes out.
--paulr

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Thursday, September 14, 2017 3:33 PM
> To: Chris Quenelle
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Prologue instructions having line information
> 
> 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  d...@lists.llvm.org> 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  d...@lists.llvm.org> 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-
> 

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please help fix!

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Hans
> Wennborg via llvm-dev
> Sent: Thursday, August 24, 2017 6:06 PM
> To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-...@lists.llvm.org)
> Subject: [llvm-dev] [5.0.0 Release] Only 3 release blockers left, please
> help fix!
> 
> Hello everyone,
> 
> We started the week with 32 open release blockers and are now down to only
> 3:
> https://bugs.llvm.org/buglist.cgi?f1=blocked=equals=33849_form
> at=advanced=---
> Many thanks for your hard work so far.
> 
> None of the three remaining ones have any traction, so any help would
> be much appreciated:
> 
> https://llvm.org/pr33668
> "Excessive memory and CPU use in tail duplication and associated
> passes due to critical edge splitting"
> Sounds like someone familiar with taildup is needed.
> 
> https://llvm.org/pr33930
> "Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped
> immediately"' failed."
> Needs someone familiar with debug info.

See https://reviews.llvm.org/D37038 and comments from Adrian Prantl.
I hope to have time to look at this today, but can't guarantee results.
--paulr

> 
> https://llvm.org/pr33507
> "Assertion failed: Shift >= 0, file
> C:\src\llvm_package_303050\llvm\tools\clang\lib\Format\WhitespaceManager.c
> pp,
> line 245"
> clang-format asserts and breaks the correctness of some code. This
> seems bad. Needs someone familiar with clang-format.
> 
> If we can get these squashed, I'll be a very happy release manger.
> 
> Thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Xcode and Pascal (FPC)

[Robinson, Paul via lldb-dev]

I am not an LLDB developer, but based on the symptom you reported,
there are a couple of different possibilities for why it occurs.
One possibility is that FPC up-shifts all the names in the debug info,
but does not add the "case-insensitive" indication.  This would be a
bug in the compiler.
Another is that FPC does add the indication but LLDB is not looking
for it, and always does case-sensitive matching.  This would be a bug 
in LLDB.
In either case it seems there is no good workaround.
--paulr


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of via
> lldb-dev
> Sent: Thursday, March 16, 2017 1:25 AM
> To: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Xcode and Pascal (FPC)
> 
> Hi,
> 
> I have no answer received yet to this question.
> Maybe this list / forum is not the appropriate place for this kind of
> question.
> 
> If this is the case please advise me to whom I should address myself.
> 
> …or is it just a wast of time to try to improve displaying Pascal variable
> names (not case-sensitive) with the  LLDB Debugger?
> 
> Thanks in advance,
> 
> Best regards,
> 
> Marc
> 
> 
> 
> Van: Marc ROOSE >
> Datum: donderdag 9 maart 2017 13:33
> Aan: "lldb-dev@lists.llvm.org"  d...@lists.llvm.org>
> Onderwerp: Xcode and Pascal (FPC)
> 
> Hi,
> 
> For many years I’m using Xcode to compile and debug source code written in
> Pascal (Free Pascal Compiler).
> Previously using the gdb-debugger.
> 
> With the lldb debugger the "Debug Bar-Proces Controls" and breakpoints
> still works fine.
> Variables values are displayed in the "View variables”.
> Thanks to the LLDB Debugger development team!
> 
> But the Pascal language is not case-sensitive.
> All variable names are displayed in upper case, thus for printing values
> in the “View console output” the variable names has to be typed in upper
> case.
> Consequently copy and past of the variable names from the source editor
> can’t be used.
> Unfortunately also inspecting variables directly in the source editor will
> not work, unless they are typed in upper case.
> 
> Using the lldb-debugger would be much more practical if Pascal variable
> names could be copy/past directly from source editor into the console
> and/or Pascal variables could be inspected directly into the source
> editor.
> 
> Any workaround work around or recommendations how to solve this issue?
> 
> I really appreciate any help someone can provide.
> 
> 
> Marc
> 
> 
> 
> ___
> 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] Recent Linux test failures

[Robinson, Paul via lldb-dev]

Also, if I do 'ninja check-all' then I get a compile-time error in
lldb/unittests/Core/LogTest.cpp (line 24):
could not convert '(const char*)"log foo"' from 'const char*' to 
'llvm::StringLiteral'

Thanks,
--paulr


> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Robinson, Paul via lldb-dev
> Sent: Tuesday, February 28, 2017 9:10 AM
> To: LLDB Dev (lldb-dev@lists.llvm.org)
> Subject: [lldb-dev] Recent Linux test failures
> 
> Yesterday I mentioned that I had some LLDB test failures while trying an
> LLVM patch, and Pavel requested more details.
> 
> This morning I built clang/llvm/lldb r296443; I had done
>   cmake -DLLDB_TEST_COMPILER=$PWD/bin/clang
> so that 'ninja check-lldb' would make use of the just-built clang.
> 
> 'ninja check-lldb' reported 3 Failures and 12 Errors.  I found some
> log files in 'lldb-test-traces' so I zipped up Failure* and attached
> it to this email.  Let me know if you need other information.
> 
> Thanks,
> --paulr

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

Re: [lldb-dev] DWARF v5 unit headers

[Robinson, Paul via lldb-dev]

Thanks for the feedback!  Clang will continue to emit v4 by default for quite 
some time, the v5 work is just getting started.
Would someone like to be subscribed to LLVM reviews that do new v5 work?  Or 
just rely on us remembering to send notes to lldb-dev?
Once I get the unit headers in place, my focus is likely to be on the features 
that reduce the number of relocations that the linker has to process.  This 
would include the new indirect forms for strings and addresses.

Pavel, I will start a new thread about the failures I see on Linux.
Thanks,
--paulr

From: Pavel Labath [mailto:lab...@google.com]
Sent: Tuesday, February 28, 2017 3:55 AM
To: Robinson, Paul
Cc: LLDB Dev (lldb-dev@lists.llvm.org); Tamas Berghammer
Subject: Re: [lldb-dev] DWARF v5 unit headers

Thanks for the heads up Paul. I've tried your change on linux, and I don't see 
any regressions, so it should be safe to land.

Regarding the test failures you were seeing: what is the system you were 
testing this on? If it is linux, could you send me the list of failures -- I'd 
be interested in getting them sorted out.

regards,
pavel



On 28 February 2017 at 11:45, Tamas Berghammer via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:
As far as I know the only dwarf v5 functionality currently implemented in LLDB 
is the split dwarf support so I don't expect it to work with the new dwarf v5 
data but as long as clang emits dwarf v4 (or older) by default it shouldn't 
cause any immediate problem with the test suite (we will still have to teach 
LLDB to handle dwarf v5).

For the future changes, when you start to emit the new dwarf v5 tag and form 
values instead of the current GNU extension tag and form values for split dwarf 
and for the related new data form-s we will have to teach LLDB to understand 
them (currently we expect only the GNU versions) so a heads up for that change 
would be appreciated. Other then this I expect no issue regarding the addition 
of dwarf v5 support for LLDB.

Tamas

On Tue, Feb 28, 2017 at 5:25 AM Robinson, Paul via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>> wrote:
I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
cause Clang/LLVM to emit correct unit headers if you ask for version 5.
I've run the lldb tests and I *think* I pointed to my modified Clang
correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
not introduce new problems.
I saw 3 Failure and 12 Error with or without the patch.
(One Expected Failure seems to have become an Unexpected Success. Haven't
tried to decipher logs to figure out which one yet.)

If anybody can predict a problem with my patch, please let me know by
noon Pacific time (2000 GMT) tomorrow (28th).

We're going to be doing more work implementing various bits of DWARF v5
in the coming months.  If anybody thinks they can predict that there are
particular bits that would be especially problematic for LLDB, it would
be useful to know up front which bits those are.

Thanks
--paulr

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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto: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] DWARF v5 unit headers

[Robinson, Paul via lldb-dev]

I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
cause Clang/LLVM to emit correct unit headers if you ask for version 5.
I've run the lldb tests and I *think* I pointed to my modified Clang
correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
not introduce new problems.
I saw 3 Failure and 12 Error with or without the patch.
(One Expected Failure seems to have become an Unexpected Success. Haven't
tried to decipher logs to figure out which one yet.)

If anybody can predict a problem with my patch, please let me know by
noon Pacific time (2000 GMT) tomorrow (28th).

We're going to be doing more work implementing various bits of DWARF v5
in the coming months.  If anybody thinks they can predict that there are 
particular bits that would be especially problematic for LLDB, it would 
be useful to know up front which bits those are.

Thanks
--paulr

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

[lldb-dev] FW: [Dwarf-Discuss] DWARF Version 5 Standard Released

[Robinson, Paul via lldb-dev]

-Original Message-
From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf 
Of Michael Eager
Sent: Wednesday, February 15, 2017 12:11 PM
To: DWARF Workgroup; DWARF
Subject: [Dwarf-Discuss] DWARF Version 5 Standard Released

The DWARF Debugging Information Format Standards Committee is pleased to 
announce the availability 
of Version 5 of the DWARF Debugging Format Standard.   The DWARF Debugging 
Format is used to 
communicate debugging information between a compiler and debugger to make it 
easier for programmers 
to develop, test, and debug programs.

DWARF is used by a wide range of compilers and debuggers, both proprietary and 
open source, to 
support debugging of Ada, C, C++, Cobol, FORTRAN, Java, and other programming 
languages. DWARF V5 
adds support for new languages like Rust, Swift, Ocaml, Go, and Haskell, as 
well as support for new 
features in older languages. DWARF can be used with a wide range of processor 
architectures, such as 
x86, ARM, PowerPC, from 8-bit to 64-bit.

DWARF is the standard debugging format for Linux and several versions of Unix 
and is widely used 
with embedded processors. DWARF is designed to be extended easily to support 
new languages and new 
architectures.

The DWARF Version 5 Standard has been in development for six years. DWARF 
Committee members include 
representatives from over a dozen major companies with extensive experience in 
compiler and debugger 
development. Version 5 incorporates improvements in many areas: better data 
compression, separation 
of debugging data from executable files, improved description of macros and 
source files, faster 
searching for symbols, improved debugging of optimized code, as well as 
numerous improvements in 
functionality and performance.

The DWARF Version 5 Standard can be downloaded without charge from the DWARF 
website (dwarfstd.org). 
Additional information about DWARF, including how to subscribe to the DWARF 
mailing list, can also 
be found on the website. Questions about the DWARF Debugging Information Format 
or the DWARF 
Committee can be directed to the DWARF Committee Chair, Michael Eager at 
i...@dwarfstd.org.

-- 
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
___
Dwarf-Discuss mailing list
dwarf-disc...@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RTTI does not work stable in LLDB.

[Robinson, Paul via lldb-dev]

Yes, I do get that it was just unfortunate timing.  Sorry for failing at being 
light-hearted.

I suspect the compiler can be persuaded to emit a name consistent with the 
demangling of the vtable name.  Despite being the way-things-have-worked for a 
long time, it still seems moderately fragile, especially in the face of various 
compiler-list debates about what the name actually should contain.
--paulr

From: Greg Clayton [mailto:gclay...@apple.com]
Sent: Monday, February 06, 2017 4:38 PM
To: Robinson, Paul
Cc: Zachary Turner; LLDB Dev (lldb-dev@lists.llvm.org)
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.


On Feb 6, 2017, at 3:38 PM, Robinson, Paul 
> wrote:

It's not practical for the DWARF to try to identify the actual address of the 
vtable; that address might not be available.
it seems like we could hang onto the linkage_name of the vtable though, 
somewhere, so you wouldn't be relying on the demangler you have available at 
runtime to produce the same string that the compiler did at compile time.  The 
symbolic name of the vtable should be unambiguous (one hopes!) but not depend 
on the existence of the vtable in any particular place.
Doesn't solve the problem for today's compilers, granted.
--paulr

P.S. It would be helpful to have these things come up *before* the next rev of 
the spec is frozen.  Just sayin'.  :)


We had just identified this today and realized it was a problem so we had no 
idea there was a problem until today. Debuggers have been doing this pretty 
reliably for the past 15 years, so it was never anything we actually needed 
extra support for since it was so easy to do.

Greg



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

Re: [lldb-dev] RTTI does not work stable in LLDB.

[Robinson, Paul via lldb-dev]

It's not practical for the DWARF to try to identify the actual address of the 
vtable; that address might not be available.
it seems like we could hang onto the linkage_name of the vtable though, 
somewhere, so you wouldn't be relying on the demangler you have available at 
runtime to produce the same string that the compiler did at compile time.  The 
symbolic name of the vtable should be unambiguous (one hopes!) but not depend 
on the existence of the vtable in any particular place.
Doesn't solve the problem for today's compilers, granted.
--paulr

P.S. It would be helpful to have these things come up *before* the next rev of 
the spec is frozen.  Just sayin'.  ☺

From: Greg Clayton [mailto:gclay...@apple.com]
Sent: Monday, February 06, 2017 2:35 PM
To: Zachary Turner
Cc: Robinson, Paul; LLDB Dev (lldb-dev@lists.llvm.org)
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.

It just says where it is inside the class itself, not what the value of the 
vtable pointer is:

0x6628: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "base_type" )
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.cpp" )
 AT_decl_line( 6 )

0x6634: TAG_member [4]
 AT_name( "_vptr$base_type" )
 AT_type( {0x4a41} ( __vtbl_ptr_type* ) )
 AT_data_member_location( 0x00 )
 AT_artificial( true )
Just says “the vtable is at offset zero inside the class”. Not helpful for 
reading any vtable pointer and trying to figure out which class it belongs to.

Greg

On Feb 6, 2017, at 2:25 PM, Zachary Turner 
> wrote:

Doesn't the DWARF have a record for the VTable itself?  I know PDB does, you 
can look up the class name through the VTable debug info record rather than 
trying to demangle the name.

On Mon, Feb 6, 2017 at 2:21 PM Greg Clayton via lldb-dev 
> wrote:
Yeah, when doing dynamic type resolution, we look at the first pointer inside 
the pointer and see if it resolves to a virtual table symbol. If it does, we 
extract the class name from the demangled symbol name and try to look up. GDB 
does the same thing. All debuggers do AFAIK.

If the DWARF specified the vtable address in the DWARF on the class definition 
this would help, but without that the only thing we can really do is to try and 
figure out the class and look it up by name. Also, even if this is added to 
future DWARF, it doesn’t fix the problem that we have many compilers that don’t 
have the info so we would still need to do what we do.

If anyone has any better ideas I am all ears?

Greg

On Feb 6, 2017, at 11:48 AM, Robinson, Paul 
> wrote:

So is LLDB expecting the name in the DWARF info to match the demangled name of 
the vtable pointer?  The DWARF spec does not really specify what the name of a 
template instantiation should be, and in particular does not *want* to specify 
whether it matches any given demangler's opinion of the name.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Monday, February 06, 2017 11:08 AM
To: Greg Clayton
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.

So I found the problem. This is a compiler bug. The DWARF for this type looks 
like:

0x65da: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "derived0" )
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.cpp" )
 AT_decl_line( 9 )

But all of the type info in the symbol table has has the type named as 
"derived0”. Note the extra “u” that follows 1024. This stops 
LLDB from being able to lookup the type correctly so we can show the dynamic 
type. In LLDB we check the first pointer inside of a class to see if it is a 
symbol whose name is “vtable for TYPENAME”. If it is, we lookup the type 
“TYPENAME” to find it. In this case we try to lookup "derived0” and we fail since the DWARF has it as "derived0”.

I have filed a radar on the compiler here at Apple for the fix.

Greg


On Feb 6, 2017, at 10:22 AM, Greg Clayton via lldb-dev 
> wrote:

I am looking at this now. I will let you know what I find.

Greg

On Feb 6, 2017, at 10:00 AM, Roman Popov 
> wrote:

Yes, that was my thought.

FYI, checked in GDB: it's working correctly on this testcase showing correct 
dynamic type in both cases.

2017-02-06 9:48 GMT-08:00 Greg Clayton 
>:
You have found a 

Re: [lldb-dev] RTTI does not work stable in LLDB.

[Robinson, Paul via lldb-dev]

So is LLDB expecting the name in the DWARF info to match the demangled name of 
the vtable pointer?  The DWARF spec does not really specify what the name of a 
template instantiation should be, and in particular does not *want* to specify 
whether it matches any given demangler's opinion of the name.
--paulr

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
Clayton via lldb-dev
Sent: Monday, February 06, 2017 11:08 AM
To: Greg Clayton
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] RTTI does not work stable in LLDB.

So I found the problem. This is a compiler bug. The DWARF for this type looks 
like:

0x65da: TAG_structure_type [112] *
 AT_containing_type( {0x6628} )
 AT_name( "derived0" )
 AT_byte_size( 0x08 )
 AT_decl_file( "/private/tmp/main.cpp" )
 AT_decl_line( 9 )

But all of the type info in the symbol table has has the type named as 
"derived0”. Note the extra “u” that follows 1024. This stops 
LLDB from being able to lookup the type correctly so we can show the dynamic 
type. In LLDB we check the first pointer inside of a class to see if it is a 
symbol whose name is “vtable for TYPENAME”. If it is, we lookup the type 
“TYPENAME” to find it. In this case we try to lookup "derived0” and we fail since the DWARF has it as "derived0”.

I have filed a radar on the compiler here at Apple for the fix.

Greg



On Feb 6, 2017, at 10:22 AM, Greg Clayton via lldb-dev 
> wrote:

I am looking at this now. I will let you know what I find.

Greg

On Feb 6, 2017, at 10:00 AM, Roman Popov 
> wrote:

Yes, that was my thought.

FYI, checked in GDB: it's working correctly on this testcase showing correct 
dynamic type in both cases.

2017-02-06 9:48 GMT-08:00 Greg Clayton 
>:
You have found a bug. It should be reporting this correctly but it isn’t. I 
verified it fails on MacOSX.

Greg Clayton

On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev 
> wrote:

Hello,
I'm observing very strange LLDB behavior: it does not always shows a correct 
dynamic type when I ask for.

Originally I was working with LLDB 3.9, but it looks like trunk version behaves 
the same strange way.

I was able to capture this behavior in a small code snippet:

#include 
#include 

using namespace std;

struct base_type {  virtual ~base_type(){} };

template 
struct derived0 : base_type {};

template 
struct derived1 : base_type {};

int main(int argc, char ** argv) {

base_type * bptr0 = new derived0();
base_type * bptr1 = new derived1();

cout << typeid(*bptr0).name() << endl;
cout << typeid(*bptr1).name() << endl;

return 0;
}


lldb --version
lldb version 5.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision 293398)
  clang revision 293398
  llvm revision 293398


Testing in LLDB:
(lldb) break set --file main.cpp --line 22

(lldb) expression -d no-run --  bptr1
(derived1 *) $2 = 0x00614c40

(lldb) expression -d no-run --  bptr0
(base_type *) $3 = 0x00614c20


Can someone explain me why for bptr0 I dont get a  derived0 * 
as I expected?


Thanks,
Roman
___
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] [cfe-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Robinson, Paul via lldb-dev]

Also, compiler-rt release_40 not set up yet?
Thanks,
--paulr

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Anton
> Korobeynikov via cfe-dev
> Sent: Friday, January 13, 2017 9:31 AM
> To: Hans Wennborg
> Cc: llvm-dev; Nicolai Hähnle; cfe-dev; openmp-dev (openmp-
> d...@lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [llvm-dev] [4.0.0 Release] The branch is here, the
> release process starts
> 
> That's odd... Have the branch created as usual?
> 
> On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg  wrote:
> > Oh wait, the branch on the git mirror doesn't look right!
> >
> > Anton, can you take a look? The first commit on the branch for llvm is:
> >
> > 
> > r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line
> >
> > Drop 'svn' suffix from version.
> > 
> >
> > It should be similar for cfe and the others.
> >
> > The current git mirror branch for llvm seems to only have one commit,
> > and that's one I just made:
> >
> > $ git log --oneline origin/release_40
> > 817cc1a7301 Merging r291863:
> > 
> > r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
> > line
> >
> > Note that it doesn't have any parent!
> >
> > On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg 
> wrote:
> >> It's there for me now:
> >>
> >> $ git fetch origin
> >> remote: Counting objects: 811, done.
> >> remote: Compressing objects: 100% (561/561), done.
> >> remote: Total 562 (delta 462), reused 2 (delta 0)
> >> Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
> >> Resolving deltas: 100% (462/462), completed with 240 local objects.
> >> From http://llvm.org/git/llvm
> >>233ecbde652..16c5e12d3a5  master -> origin/master
> >>  * [new branch]  release_40 -> origin/release_40
> >>
> >>
> >> On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle 
> wrote:
> >>> I don't see the release branch in the Git mirror at
> >>> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
> >>>
> >>> Thanks,
> >>> Nicolai
> >>>
> >>>
> >>> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
> 
>  Dear everyone,
> 
>  It has begun: the release branch was recently created from trunk at
>  r291814 and the trunk version was subsequently incremented to 5.0.0
>  (as per the new versioning scheme [1]).
> 
>  Release blockers are tracked by http://llvm.org/PR31622 Please mark
>  any bugs, old or new, that you think need to be fixed before the
>  release as blocking that.
> 
>  Please help me out in staying on top of the release by cc'ing me on
>  any bugs, commits, or other issues you think may be relevant. If I'm
>  not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
>  but email is more reliable.
> 
>  If you know of any committs that occurred close to the branch that
>  need to be reverted or merged, please let me know.
> 
>  To get a change committed to the branch, first commit to trunk as
>  usual, and then reply to the commit message on the mailing list with
>  myself and the code owner cc'd, asking for the change to be merged to
>  the branch. Alternatively, make the request by filing a bug blocking
>  PR31622.
> 
>  Release notes should be committed directly to the branch. If you know
>  of any significant change made since the last release, it should get
>  mentioned in the notes.
> 
>  What's next? Once the branch is in good shape, hopefully within a few
>  days, a first release candidate will be made available for testing.
>  The schedule for the release is under "Upcoming Releases" on
>  http://llvm.org.
> 
>  Thanks,
>  Hans
> 
> 
>   [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>  ___
>  LLVM Developers mailing list
>  llvm-...@lists.llvm.org
>  http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> >>>
> 
> 
> 
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
> ___
> 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

Re: [lldb-dev] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Michal
> Górny via cfe-dev
> Sent: Monday, December 05, 2016 3:33 PM
> To: Hans Wennborg via lldb-dev
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> cfe-dev
> Subject: Re: [cfe-dev] [lldb-dev] [Release-testers] [Openmp-dev] [4.0
> Release] Schedule and call for testers
> 
> On Mon, 5 Dec 2016 12:07:25 -0800
> Hans Wennborg via lldb-dev  wrote:
> 
> > On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin 
> wrote:
> > > On 5 December 2016 at 19:56, Hans Wennborg  wrote:
> > >> I'd like to avoid 4.1 because of the potential for confusion about
> > >> whether it's a major release (as it would have been under the old
> > >> scheme) or a patch release.
> > >
> > > But if the versioning scheme is different, users will have to
> > > understand what it means anyway.
> > >
> > > Until now we had a weird and very unique logic, and we're moving to a
> > > more sensible logic, because it's similar to what some other projects
> > > are doing.
> > >
> > > I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> > > that used to be weird before.
> > >
> > > After a few releases everything will be clear anyway... I really don't
> > > want to make the foreseeable future weird again to avoid a potential
> > > misunderstanding for one or two releases.
> > >
> > > Let's just be brutally clear in all release communications and
> > > hopefully people will understand.
> > >
> > >
> > >> The alternative would be:
> > >>
> > >> 3.9.0
> > >> 3.9.1
> > >> 4.0.0
> > >> 4.1.0 <-- Can't tell from the version number what kind of release
> this is.
> > >
> > > No, that has a redundant zero, too.
> > >
> > > The alternative is:
> > >
> > > 3.9.0
> > > 3.9.1
> > > 4.0
> > > 4.1
> > > 5.0
> > > 5.1
> >
> > I'm worried that users will, with some reason, think that the 4.1 and
> > 5.1 releases are the same kind as 2.1 and 3.1 :-/
> 
> Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

Back in the day, every version was identified as "Latest."
No possible confusion there!

I'm fine with "4.0.1" in keeping with the major.minor.patch convention,
given how the in-betweeners are really patch updates not minor versions.
--paulr

> 
> --
> Best regards,
> Michał Górny
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Closing spam bugs has a consequence, be aware

[Robinson, Paul via lldb-dev]

I just went in and bulk-closed a dozen or so of today's spam bugs.
This made me realize that doing so sends an email to the submitter's
address, which allows the submitter to collect valid addresses of
the people who are trying to clean up the mess.

Anyone who wants to help with the cleanup, that's great, but just
be aware of this consequence--you are likely to be (more) targeted
by spammers in the future.
--paulr

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

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

[Robinson, Paul via lldb-dev]

I could see wanting to compare data from master and a release branch.  If that 
means sequential IDs need to work across branches, then we're back to needing a 
fancier solution than 'rev-list –count'.
--paulr

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Chris 
Matthews via llvm-dev
Sent: Thursday, July 07, 2016 5:56 PM
To: Renato Golin via llvm-foundation; Renato Golin; Mehdi Amini
Cc: LLVM Dev; llvm-foundat...@lists.llvm.org; Clang Dev; LLDB Dev
Subject: Re: [llvm-dev] [llvm-foundation] Sequential ID Git hook

Sequential IDs are important for LNT and llvmlab bisection tool.

LNT uses the “order” to capture the measured software changes.  LNT does make 
the assumption that orders are unique, so if a ID was the same on two branches, 
LNT would assume that is the same change.  If you never want to compare data 
between branches, storing each branch in a different database solves that 
problem, but sometimes you do want to directly compare runs in two branches.

With both llvmlab and LNT, once you get to a range of IDs, it is needs to be 
easy to find out what commits or commit range those IDs map to.  When given 
regression between 123 and 225, I need the list of commits, and I don’t want to 
log grep for those numbers. Ideally it should also easy for those tools to link 
to a revision on a webUI like viewvc.



On July 5, 2016 at 4:04:05 PM, Renato Golin via llvm-foundation 
(llvm-foundat...@lists.llvm.org) wrote:

On 5 Jul 2016 10:45 p.m., "Mehdi Amini" 
> wrote:
>
>
> > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev 
> > > wrote:
> >
> > Quick re-cap.
> >
> > After a few rounds, not only the "external server" proposal got
> > obliterated as totally unnecessary, but the idea that we may even need
> > a hook at all is now challenged.
>
> This is not clear to me.
> How is the umbrella repository updated?

Sorry, I meant no hooks for updating sequential ids. We still need a hook to 
update the umbrella project.

Cheers,
Renato
___
llvm-foundation mailing list
llvm-foundat...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-foundation
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

[Robinson, Paul via lldb-dev]

> On 6 Jul 2016, at 16:16, Robinson, Paul  wrote:
> >
> > As Daniel pointed out, an enumeration like that knows no bounds, and
> > starting a list invites endless what-if questions.  That's why I settled
> > for a more qualitative statement; we have to acknowledge that ultimately
> > there's a judgement call on the part of the enforcement committee, but
> > the wording as it was felt a little too wide-open for me.
> 
> That I was explicitly *not* what I was suggesting an enumeration of all
> possible cases, I was suggesting an additional document describing
> hypothetical case studies and whether they would be covered.  There is
> ample precedent for this in law (for example, much of the tax code in the
> UK comes along with guidance notes, which are not considered legally
> binding but provide people with rough rules of thumb) and does not
> degenerate into an attempt to list every possible case.
> 
> David

Ah, okay!  Like non-normative guidance/motivation text in a standards
document.  That works.
--paulr

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] Sequential ID Git hook

[Robinson, Paul via lldb-dev]

From: Renato Golin [mailto:renato.go...@linaro.org] 
Sent: Thursday, June 30, 2016 4:15 PM
To: Robinson, Paul
Cc: Clang Dev; LLDB Dev; LLVM Dev; Reid Kleckner; llvm-foundat...@lists.llvm.org
Subject: RE: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook


On 30 Jun 2016 10:20 p.m., "Robinson, Paul"  wrote:
> We've since stopped creating the tags, and gotten used to not having
> them.  We do the 'rev-list --count' trick which mainly gets recorded as
> one component of the version number, and it has been working for us.
Does that work for sub modules inside the umbrella project? 

I don't know, we don't use submodules, we use subtree merges to create
an omnibus branch.  If it *does* work in the parent project, that would
be cool (and might motivate us to reorganize our internal branches that
way, but not this year).
--paulr
 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] Sequential ID Git hook

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Renato
> Golin via cfe-dev
> Sent: Thursday, June 30, 2016 9:49 AM
> To: Reid Kleckner
> Cc: LLVM Dev; llvm-foundat...@lists.llvm.org; Clang Dev; LLDB Dev
> Subject: Re: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook
> 
> On 30 June 2016 at 17:33, Reid Kleckner  wrote:
> > Agreed, the llvm-project repository can completely take on the role of
> the
> > SQL database in Renato's proposal.
> 
> Hum, doing it in a separate server was suggested by the GitHub folks,
> so I just assumed they can't do that in the umbrella project for some
> reason.
> 
> I'm all for using the umbrella if we can, I just though we couldn't... :(
> 
> Can someone try the suggested tag style? Are we sure we can guarantee
> atomicity in there? I know SQL can. :)
> 
> I know that changing the commit message works because of Gerrit and
> our current SVN integration, I don't know how much adding one tag for
> each push will work in Git over time.

We were using tags for a while in our own SVN->git conversion internally.
(git branch is pushed to SVN and the SVN r-number used to create a tag.)
They are convenient for some things, but each tag adds a new (if small)
file to .git/tags and I don't know that it really scales well when you
are talking about (long term) hundreds of thousands of them.  That was
not what tags were designed for.

We've since stopped creating the tags, and gotten used to not having
them.  We do the 'rev-list --count' trick which mainly gets recorded as
one component of the version number, and it has been working for us.

I think having the number in the commit log (even if it's just for the
superproject) would be preferable.  You can use 'git log --grep' to
find a particular rev if you need to.
--paulr

> 
> cheers,
> --renato
> ___
> 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

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> > I still don’t understand what “confusion” could be caused by going from
> 3.9 to 4.0.  Could someone please elaborate on what the problem is that
> needs solving?  If it is that people don’t understand what is major about
> the release, I would say “who cares”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

Somebody proposed a time-based-version bitcode compatibility policy.
IMHO the easiest to remember would be "X.Y supports back to (X-1).Y"
but opinions vary (e.g. 3 years, where my idea would mean 5 years) and
nobody has tried to nail one down.

Of course actually removing an auto-upgrade feature means having to do
the archaeology to figure out when each piece was introduced, and then
how to disentangle it cleanly.  I'm not aware that these things are
identified by version, other than by researching the commit history.
With the old scheme, you'd just rip it all out at 4.1 without having
to worry about when each piece was introduced.  With the time-based
scheme there's a higher barrier to removing the old code.
--paulr

> 
> But if you really insist on 4.0 rather than 3.10, I will of course honour
> that.
> 
> Cheers,
> Hans

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Robinson, Paul via lldb-dev]

| Note that 81 > 8, so those examples would still work.
Right, but also 81 > 9 so that example would not work, if you don't understand 
how the project does version numbers.

As different projects work by different rules, I guess the interpretation of 
version numbers by other tools would have to be project-dependent.  So, all 
that matters is that LLVM asserts what rule it will follow (and then actually 
follows it!).  The Wikipedia quote seems to suggest that whole-number tuples 
(e.g.: 3.8, 3.9, 3.10) are more common than decimal strings (e.g.: 3.8, 3.81, 
3.9) and so we should not be afraid to use tuples.
--paulr

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Adrian 
McCarthy via llvm-dev
Sent: Thursday, June 16, 2016 10:03 AM
To: Bruce Hoult
Cc: llvm-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev; cfe-dev; 
Robinson, Paul
Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] What version comes after 3.9? 
(Was: [3.9 Release] Release plan and call for testers)

>Version numbers aren't strings, and they aren't floating point numbers, they 
>are a series of integers separated by dots. I can't think of a project where 
>interpreting version numbers that way won't work.

TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e), 
Opera (decimal number).

Sayeth 
Wikipedia:
Most free and open-source software packages, including MediaWiki, treat 
versions as a series of individual numbers, separated by periods, with a 
progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, 
and so on. On the other hand, some software packages identify releases by 
decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc.

Note that 81 > 8, so those examples would still work.  But 3.10 is easy to 
misinterpret as 3.1.

On Thu, Jun 16, 2016 at 2:46 AM, Bruce Hoult via lldb-dev 
> wrote:
Bug in cmake (or more likely the makefile?), pure and simple. Version numbers 
aren't strings, and they aren't floating point numbers, they are a series of 
integers separated by dots. I can't think of a project where interpreting 
version numbers that way won't work.

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> Sent: Monday, June 13, 2016 9:27 AM
> To: Robinson, Paul
> Cc: Rafael Espíndola; Tom Stellard; llvm-...@lists.llvm.org; Release-
> testers; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> On Mon, Jun 13, 2016 at 9:24 AM, Robinson, Paul via cfe-dev
>  wrote:
> >
> >
> >> -Original Message-
> >> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> >> Rafael Espíndola via llvm-dev
> >> Sent: Monday, June 13, 2016 7:47 AM
> >> To: Tom Stellard
> >> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> >> LLDB Dev; cfe-dev
> >> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
> >>
> >> On 13 June 2016 at 10:11, Tom Stellard  wrote:
> >> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> >> >> > The 4.1 release gives us the opportunity to drop support for 3.x
> >> >> > bitcode formats, so  I don't think we should move to 4.x until we
> >> have
> >> >> > older bitcode features that we really want to drop.  There should
> >> >> > probably be a separate discussion thread about this.
> >> >>
> >> >> It give the opportunity, not the obligation. Given that I think it
> is
> >> >> an independent issue and would suggest we just keep the revisions
> >> >> simple and switch trunk to 4.0.
> >> >>
> >> >
> >> > Hi Rafael,
> >> >
> >> > The main issue I see with automatically moving to 4.0, is that if a
> year
> >> > from now we decide we want to drop a bitcode feature, we can't really
> do
> >> > it unless we bump the major version again to 5.0.  If we continue on
> >> > with 3.x, then we still have the flexibility to drop bitcode features
> >> > when we decide it's necessary.
> >>
> >> OK, I guess that is where your reading of the version differ.
> >>
> >> I read that we promise that 4.0 will read all of 3.X, but make no
> >> further promises. That means that in 4.1 we *can* drop support for all
> >> 3.x, keep support for everything or something in the middle. But that
> >> is also true for 4.2. So for example it would be valid that
> >>
> >> * 4.0 reads all of 3.x
> >> * 4.1 reads >= 3.1
> >> * 4.2 reads >= 3.3
> >
> > I don't know that the actual policy has ever been formally documented,
> > although it has been discussed from time to time, so it's not too
> > surprising that people have different ideas of what the policy is.
> >
> > Maybe documenting the release-numbering-semantics policy alongside
> > the release-timing policy would be a good idea?
> 
> If someone could just let me know what the policy actually is.. ;-)

I think this is probably a case where the best approach is to write up
*some* kind of policy, and then it gets thrashed out in review.
--paulr

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

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> Rafael Espíndola via llvm-dev
> Sent: Monday, June 13, 2016 7:47 AM
> To: Tom Stellard
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev; cfe-dev
> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
> 
> On 13 June 2016 at 10:11, Tom Stellard  wrote:
> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> >> > The 4.1 release gives us the opportunity to drop support for 3.x
> >> > bitcode formats, so  I don't think we should move to 4.x until we
> have
> >> > older bitcode features that we really want to drop.  There should
> >> > probably be a separate discussion thread about this.
> >>
> >> It give the opportunity, not the obligation. Given that I think it is
> >> an independent issue and would suggest we just keep the revisions
> >> simple and switch trunk to 4.0.
> >>
> >
> > Hi Rafael,
> >
> > The main issue I see with automatically moving to 4.0, is that if a year
> > from now we decide we want to drop a bitcode feature, we can't really do
> > it unless we bump the major version again to 5.0.  If we continue on
> > with 3.x, then we still have the flexibility to drop bitcode features
> > when we decide it's necessary.
> 
> OK, I guess that is where your reading of the version differ.
> 
> I read that we promise that 4.0 will read all of 3.X, but make no
> further promises. That means that in 4.1 we *can* drop support for all
> 3.x, keep support for everything or something in the middle. But that
> is also true for 4.2. So for example it would be valid that
> 
> * 4.0 reads all of 3.x
> * 4.1 reads >= 3.1
> * 4.2 reads >= 3.3

I don't know that the actual policy has ever been formally documented,
although it has been discussed from time to time, so it's not too
surprising that people have different ideas of what the policy is.

Maybe documenting the release-numbering-semantics policy alongside
the release-timing policy would be a good idea?
--paulr

> 
> Cheers,
> Rafael
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Tom
> Stellard via cfe-dev
> Sent: Monday, June 13, 2016 7:12 AM
> To: Rafael Espíndola
> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev; cfe-dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
> > > The 4.1 release gives us the opportunity to drop support for 3.x
> > > bitcode formats, so  I don't think we should move to 4.x until we have
> > > older bitcode features that we really want to drop.  There should
> > > probably be a separate discussion thread about this.
> >
> > It give the opportunity, not the obligation. Given that I think it is
> > an independent issue and would suggest we just keep the revisions
> > simple and switch trunk to 4.0.
> >
> 
> Hi Rafael,
> 
> The main issue I see with automatically moving to 4.0, is that if a year
> from now we decide we want to drop a bitcode feature, we can't really do
> it unless we bump the major version again to 5.0.  If we continue on
> with 3.x, then we still have the flexibility to drop bitcode features
> when we decide it's necessary.
> 
> -Tom

+1.  My understanding is that 2.9->3.0 came with some huge internal changes
(overhaul of the type system, maybe? this slightly predates my involvement
with LLVM so I'm not entirely sure) and warranted a major-version change
regardless of the .9->.0 thing.

I don't think 3.10 should be confusing to anyone, really.  The version
number is a tuple, not a string or a decimal fraction.
--paulr

> 
> > Cheers,
> > Rafael
> ___
> 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

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> > How do you get monotonically increasing number with a history graph?
> 
> I think what we're trying to get is a "pushed" revision number, i.e.
> tracking the state of the upstream repositories at a given time.

I think I've mentioned this before but internally we are (mostly) using
"rev-list --count --first-parent branch-name" which gives us a 
monotonically increasing number per-branch.  The --first-parent means 
each merge counts as one, which is enough for build-number uniqueness.
Unique sequential build numbers meet our internal needs.  If this number
gets incorporated into the version numbering self-reported by Clang/LLVM,
then it's not hard to map back onto git commits.
--paulr

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

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Mehdi
> Amini via llvm-dev
> Sent: Tuesday, May 31, 2016 2:38 PM
> To: Bill Kelly
> Cc: LLVM Dev; Clang Dev; LLDB Dev
> Subject: Re: [llvm-dev] GitHub anyone?
> 
> 
> > On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev  d...@lists.llvm.org> wrote:
> >
> > Chris Lattner via llvm-dev wrote:
> >> Personally, I’m hugely in favor of moving llvm’s source hosting to
> github at
> >> some point, despite the fact that I continue to dislike git as a tool
> and
> >> consider monotonicly increasing version numbers to be hugely
> beneficial.
> >
> > For whatever it's worth, our projects define a `buildnum` git alias:
> >
> >  alias.buildnum=!sh -c "git rev-list --all | wc -l"

Or the cheaper "git rev-list --count --all" if your git is new enough.
We do something like this as well.

> >
> > So from the shell:
> >
> >  $ git buildnum
> >  17475
> >
> > This number increases monotonically per commit.
> 
> It does not work with branches though (we're not really planning to have
> branches I believe), 

You can get a per-branch unique number with this tactic.  On our local
branches we use "rev-list origin/master.." which is the number of commits
since branching from master, and that's enough for our local purposes.

> but more importantly it won't handle cross-repository
> versioning (how do you relate the number this command prints in the llvm
> repo to the number it'll print in the clang repo?), which I believe is
> something important considering our setup.

Is it really that important?  Or are we just used to the convenience?
If the Clang build number is a tuple (cfe-number, llvm-number) instead
of a single number, how horrible is that really?  If you consider what
an out-of-tree front end probably does, it's exactly the same thing.

(I admit that locally we mush cfe+llvm into a single branch and do the
rev-list count to get a single number. But that's more for our own
convenience than anything else.)
--paulr

> 
> --
> Mehdi
> 
> 
> 
> >
> >
> > Our build scripts make this number available in various #define forms.
> >
> > (We use a little extra scripting logic to also determine whether there
> > are currently any unmerged or uncommitted changes, and add an annotation
> > to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> >
> >
> > It's all stupidly simple, but seems to work well enough for us.
> >
> >
> >
> > Regards,
> >
> > Bill
> >
> > ___
> > 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
> Sent: Tuesday, May 31, 2016 3:54 PM
> To: Robinson, Paul
> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
> Subject: Re: [llvm-dev] GitHub anyone?
> 
> 
> > On May 31, 2016, at 3:38 PM, Robinson, Paul 
> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
> Mehdi
> >> Amini via llvm-dev
> >> Sent: Tuesday, May 31, 2016 2:38 PM
> >> To: Bill Kelly
> >> Cc: LLVM Dev; Clang Dev; LLDB Dev
> >> Subject: Re: [llvm-dev] GitHub anyone?
> >>
> >>
> >>> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev  >> d...@lists.llvm.org> wrote:
> >>>
> >>> Chris Lattner via llvm-dev wrote:
>  Personally, I’m hugely in favor of moving llvm’s source hosting to
> >> github at
>  some point, despite the fact that I continue to dislike git as a tool
> >> and
>  consider monotonicly increasing version numbers to be hugely
> >> beneficial.
> >>>
> >>> For whatever it's worth, our projects define a `buildnum` git alias:
> >>>
> >>> alias.buildnum=!sh -c "git rev-list --all | wc -l"
> >
> > Or the cheaper "git rev-list --count --all" if your git is new enough.
> > We do something like this as well.
> >
> >>>
> >>> So from the shell:
> >>>
> >>> $ git buildnum
> >>> 17475
> >>>
> >>> This number increases monotonically per commit.
> >>
> >> It does not work with branches though (we're not really planning to
> have
> >> branches I believe),
> >
> > You can get a per-branch unique number with this tactic.  On our local
> > branches we use "rev-list origin/master.." which is the number of
> commits
> > since branching from master, and that's enough for our local purposes.
> >
> >> but more importantly it won't handle cross-repository
> >> versioning (how do you relate the number this command prints in the
> llvm
> >> repo to the number it'll print in the clang repo?), which I believe is
> >> something important considering our setup.
> >
> > Is it really that important?  Or are we just used to the convenience?
> 
> I don't know how important it is. How would you bisect without this
> "convenience" for instance?
> (There is nothing like "push date" in git)

I know that on a single branch, "git bisect" deals with that for you.
I've seen the talk about submodules but I have no clue how that works
or whether git-bisect can operate cleanly in that situation.
--paulr

> 
> --
> Mehdi
> 
> 
> > If the Clang build number is a tuple (cfe-number, llvm-number) instead
> > of a single number, how horrible is that really?  If you consider what
> > an out-of-tree front end probably does, it's exactly the same thing.
> >
> > (I admit that locally we mush cfe+llvm into a single branch and do the
> > rev-list count to get a single number. But that's more for our own
> > convenience than anything else.)
> > --paulr
> >
> >>
> >> --
> >> Mehdi
> >>
> >>
> >>
> >>>
> >>>
> >>> Our build scripts make this number available in various #define forms.
> >>>
> >>> (We use a little extra scripting logic to also determine whether there
> >>> are currently any unmerged or uncommitted changes, and add an
> annotation
> >>> to the program version in that case, e.g.  "9.3.17475 [unmerged]")
> >>>
> >>>
> >>> It's all stupidly simple, but seems to work well enough for us.
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Bill
> >>>
> >>> ___
> >>> 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

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