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

[Joerg Sonnenberger via lldb-dev]

On Thu, Jun 16, 2016 at 10:02:52AM -0700, Adrian McCarthy via cfe-dev wrote:
> > 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.

The only environment I know where such an interpreation is popular is
CPAN. Everyone else effectively uses Dewey-style interpretation. So yes,
some crappy software might mishandle 3.10 by using patterns like 3.1*
and not 3.1.*, but I don't believe catering to broken software is very
useful.

Joerg
___
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] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Adrian McCarthy via lldb-dev]

>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 <
lldb-dev@lists.llvm.org> 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.
>
> On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> Hello there,
>>
>> First, I would like to say that I don't have any strong opinions on this
>> matter: as mostly an user of LLVM, my basic concern is for me to be able to
>> identify which version is the newest and configure it as easily as
>> possible. That being said, I have a question about LLVM's versioning
>> strategy: is it possible for other tools (including the ones LLVM depend
>> on) to become broke or annoyingly buggy just because a bad versioning
>> scheme was put in place?
>>
>> Just to give some context to this question, I've been using OS X for a
>> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
>> X 10.10. Not at first, no: I didn't realize this would have any impact on
>> my workspace until I had to compile some code, and CMake kept stopping just
>> because it recognized that I was using an older version of the OS (emphasis
>> on *older*). It is funny when you realize that 10.10 should actually be
>> interpreted as less than 10.9, and CMake was falling for it, which was a
>> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
>> the main cause of this issue. Of course this problem can be easily arranged
>> by setting up some extra environment variables to tell CMake to target OS X
>> 10.9 instead, but that was a very irritating behavior and only happened
>> because a bunch of people (from CMake, and, then, from OS X's development
>> team) thought comparing versions directly shouldn't be a problem. Besides,
>> every one of these small details end up being some extra steps a new user
>> need to follow to be able to use a tool, some of which could be easily
>> avoided.
>>
>> I confess I didn't look into this matter after that, and still today, on
>> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
>> thus, I don't know if this bug was fixed or not. However, as I'm starting
>> to see a very similar pattern happening with LLVM on this thread, and I
>> thought I could contribute with the discussion: did someone check if naming
>> the next version "3.10" would have any impact on a production system?
>>
>>
>> --
>> Cristianno Martins
>> 
>>
>> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>>


 On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
 cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-dev" 
>> > To: "llvm-dev" , "cfe-dev" <
>> cfe-...@lists.llvm.org>, "LLDB Dev" ,
>> > "openmp-dev (openmp-...@lists.llvm.org)" > >
>> > Cc: "r jordans" , "Paul Robinson" <
>> paul_robin...@playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
>> Release] Release plan and call for testers)
>> >
>> > Breaking this out into a separate thread since it's kind of a
>> > separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to collect
>> as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>> > surprised by both.
>> >

Re: [lldb-dev] Review of API and remote packets

[Ravitheja Addepally via lldb-dev]

Hello All,

   In the context of Intel® Processor Trace support in LLDB I
asked, a while ago, about the syntax of remote packets.

   Directions were mixed:

1.   Taking GDBSERVER/GDB packets (available from 7.10)

2.   Going to a brand new packets for lldb/lldbserver (as described by
Greg).

   We consider also:

1.   Use case lldb/lldbserver can use new packets, while LLDB/gdbserver
uses the GDB ones.

2.   Use case LLDB/GDBSERVER  is decreasing in importance. We see a
gradual increase in the solutions and systems providing lldbserver as
default.

3.   GDB/lldserver is not supported.

(for all those observations please correct me if I am wrong)



In this sense we intent to follow the development using new packets for the
use case lldb/lldbserver.

But we still need a feedback on: Is the use LLDB/GDBSERVER still important?



Looking forward for your feedback!



Thanks and regards,

A Ravi Theja

On Wed, Apr 13, 2016 at 1:55 PM, Ravitheja Addepally <
ravithejaw...@gmail.com> wrote:

> Well the point of the user ids was to support multiple trace technologies
> for the same thread, so in that case the thread id is not sufficient for
> uniquely identifying the trace. Now I guess the server would need to be
> aware of the user-id if multiple trace technologies are active on the same
> thread ?
>
> On Wed, Apr 13, 2016 at 12:52 PM, Pavel Labath  wrote:
>
>> Do we need the server to know about the user ids we handed out to the
>> SB API client? AFAIK, you cannot have multiple traces of the same
>> thread running concurrently, so a thread-id should uniquely identify a
>> trace. The user id can then stay a client thing for abstracting the
>> concrete implementation details. Or am I missing something here?
>>
>>
>> On 13 April 2016 at 10:10, Ravitheja Addepally 
>> wrote:
>> > Hello,
>> >Ok for the thread id we may use this QThreadSuffixSupported
>> extension
>> > but gdb packets also don't have userid support since gdb does not have
>> the
>> > concept of user id for trace instances. Also gdb uses seperate packets
>> for
>> > trace configuration and starting the trace.
>> >
>> > On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath 
>> wrote:
>> >>
>> >> LLDB already has the QThreadSuffixSupported extension, which adds the
>> >> ";thread:" suffix to a bunch of packets. We could say that if the
>> >> client requests this extension, we will support it on these packets as
>> >> well. Otherwise we fall back to the "Hg" thingy.
>> >>
>> >> I haven't looked at how hard it would be to implement that...
>> >>
>> >> pl
>> >>
>> >> On 12 April 2016 at 09:01, Ravitheja Addepally <
>> ravithejaw...@gmail.com>
>> >> wrote:
>> >> > One of the downsides of using the gdb protocol is that these packets
>> are
>> >> > stateful meaning the thread id option is not there and the word
>> btrace
>> >> > stands for branch trace which basically suggests execution tracing.
>> >> >
>> >> > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath 
>> wrote:
>> >> >>
>> >> >> I think we should reuse packets from the gdb protocol whereever it
>> >> >> makes sense. So, if they fit your needs (and a quick glance seems to
>> >> >> confirm that), then I think you should use them.
>> >> >>
>> >> >> On 11 April 2016 at 15:28, Ravitheja Addepally
>> >> >> 
>> >> >> wrote:
>> >> >> > Hello,
>> >> >> >Regarding the packet definitions for tracing, how about
>> >> >> > reusing
>> >> >> > the
>> >> >> > existing btrace packets ?
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read
>> >> >> >
>> >> >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> We also need to think about all other types of tracing. It might
>> >> >> >> make
>> >> >> >> more
>> >> >> >> sense to keep these calls on SBProcess and have the calls simply
>> be:
>> >> >> >>
>> >> >> >>
>> >> >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions
>> >> >> >> _options,
>> >> >> >> lldb::SBError );
>> >> >> >>
>> >> >> >> And you would need to specify which threads in the SBTraceOptions
>> >> >> >> object
>> >> >> >> itself?:
>> >> >> >>
>> >> >> >> SBTraceOptions trace_options;
>> >> >> >>
>> >> >> >> And then do some like:
>> >> >> >>
>> >> >> >> trace_options.SetTraceAllThreads();
>> >> >> >>
>> >> >> >> And maybe tracing all threads is the default. Or one can limit
>> this
>> >> >> >> to
>> >> >> >> one
>> >> >> >> thread:
>> >> >> >>
>> >> >> >> trace_options.SetThreadID (tid);
>> >> >> >>
>> >> >> >> Then you start tracing using the "trace_options" which has the
>> >> >> >> notion
>> >> >> >> of
>> >> >> >> which threads to trace.
>> >> >> >>
>> >> >> >> lldb::SBError error;
>> >> >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>> >> >> >>
>> >> >> >> 

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

[Bruce Hoult via lldb-dev]

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.

On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hello there,
>
> First, I would like to say that I don't have any strong opinions on this
> matter: as mostly an user of LLVM, my basic concern is for me to be able to
> identify which version is the newest and configure it as easily as
> possible. That being said, I have a question about LLVM's versioning
> strategy: is it possible for other tools (including the ones LLVM depend
> on) to become broke or annoyingly buggy just because a bad versioning
> scheme was put in place?
>
> Just to give some context to this question, I've been using OS X for a
> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
> X 10.10. Not at first, no: I didn't realize this would have any impact on
> my workspace until I had to compile some code, and CMake kept stopping just
> because it recognized that I was using an older version of the OS (emphasis
> on *older*). It is funny when you realize that 10.10 should actually be
> interpreted as less than 10.9, and CMake was falling for it, which was a
> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
> the main cause of this issue. Of course this problem can be easily arranged
> by setting up some extra environment variables to tell CMake to target OS X
> 10.9 instead, but that was a very irritating behavior and only happened
> because a bunch of people (from CMake, and, then, from OS X's development
> team) thought comparing versions directly shouldn't be a problem. Besides,
> every one of these small details end up being some extra steps a new user
> need to follow to be able to use a tool, some of which could be easily
> avoided.
>
> I confess I didn't look into this matter after that, and still today, on
> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
> thus, I don't know if this bug was fixed or not. However, as I'm starting
> to see a very similar pattern happening with LLVM on this thread, and I
> thought I could contribute with the discussion: did someone check if naming
> the next version "3.10" would have any impact on a production system?
>
>
> --
> Cristianno Martins
> 
>
> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>>
 On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> - Original Message -
> > From: "Hans Wennborg via cfe-dev" 
> > To: "llvm-dev" , "cfe-dev" <
> cfe-...@lists.llvm.org>, "LLDB Dev" ,
> > "openmp-dev (openmp-...@lists.llvm.org)" 
> > Cc: "r jordans" , "Paul Robinson" <
> paul_robin...@playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > Breaking this out into a separate thread since it's kind of a
> > separate
> > issue, and to make sure people see it.
> >
> > If you have opinions on this, please chime in. I'd like to collect as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a
> natural forcing function here: opaque pointer types. I think we should
> increment the major version number when opaque pointer types are here, as
> it will be a major breaking change, and then we'll have a version 4.0.
> Until then, unless something else breaking comes up, 3.10 sounds fine to 
> me.
>

 +1, complete agreement.

>>>
>>> While I'm not sure opaque 

[lldb-dev] Symbolicate user processes when kernel debugging

[John Otter via lldb-dev]

I'm using lldb to debug the OS X kernel, and it works great.
I would like to have more flexibility in analysing user programs while
debugging the kernel itself,
and specifically symbolicate the code of the user programs.

For example I often use the command showthreaduserstack defined here
http://opensource.apple.com//source/xnu/xnu-2422.1.72/tools/lldbmacros/userspace.py
to take
a look at the user stack of a process running in kernel mode that just
scripts the process of
obtaining the thread saved state, but the output unfortunately isn't
symbolicated.

Is there a way to add symbols for a user process (programs and shared libs?)
I looked into the target modules add command, but when I try to add a
copy of the executable
it just says that the file I pick doesn't exist (even though it clearly exist).
Also I'm not entirely sure how that would work since the user space
addressing space changes
for every process, even if I manually set the loading address.
Would that work only for that specific process and execution?

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