[lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Are there plans to add new target: lldb-only and lldb-install? There
are already similar targets for Clang.

I'm debugging LLDB on NetBSD and I'm having very bad time building
everything with debug symbols. There is also popular request from
NetBSD users to just install lldb without conflicting with Clang and LLV
M.

I was looking at Open Source distributions with a LLDB package, for
example ArchLinux is manually copying files from the build...

I would like to skip building unnecessary parts and then focus on
installing only the LLDB package... otherwise I need 64GB of
RAM+storage and a lot of time to produce new package.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWUm4GAAoJEEuzCOmwLnZsvNsP/RLpRVdnwC8Di9wIoovAGPEk
ybsJeHHspBQNr304FEc5cgA67LOaDBNLGNGbIMCOCoSd4XnvnL484lSy2hA4nk/M
8N1XeRNdaMlw4jSexbZU7BTkIvBriTjU9ZakfFV4VbHFN04Kvf8U7nYLhQvCvA+i
+g+m0xNrBccHXPqSaZXWHH2qScEL7AibMR96UsxEOSnZFxgZoEgRDCxaETyIwtai
13EOWxSaIxAjRzylfirZRWNsujGWfOx3u5/es5Ot4t/bRy+z5gnKG2mn1UONAuON
rwpXh3hEnkhMIMvwYpjA2AyVKog1jSroMCh9ziDpGP8h77TmP8DrGg6kEww37Hjl
hT2LF3WZLLsi3shVnEpgHZQYHTiqLUQo4rTJOTJaXWa8PR17c884WXsoeC/kvUIU
ceyD2KaQv50dMA0aPkdp+hrHVa6Fws/af4S/ANHpqSFXgSYR2tYqs76mILd7FA7Y
TCWXM2Pd6P9PbobHlqdVvN4KeANUIa0Jowto44yNGLv6WZN7wS4QMrL7UtYfbK9b
rIZD1yiXg5jYcCC4QDmeiO2jxp8pVy7AP8w7S2UgMrMorbWb1rg7yY5jJFtqFQoT
vxJZMyvOVdF4ckJUlFY/k1cEIPE1920rEcRooBbZ+mDJSkWKojgG3SzskR9NECPe
MJPa+TQEyh1sgi8GkqnX
=8teZ
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23.11.2015 05:19, Zachary Turner wrote:
> LLDB links against clang and llvm.  How would an lldb-only target
> work? i.e. how would you build lldb without first building clang
> and llvm? Unless I'm misunderstanding the purpose of your
> question:
> 

I don't want to build the following executables (among others):
bin/clang
bin/clang++
bin/clang-3.8
bin/clang-check
bin/clang-cl
bin/clang-format
bin/git-clang-format

I've found that to some extend I can emulate it with:
ninja/make lldb lldb-mi

I would like to have a target lldb-only, building all LLDB targets
needed to install the full distribution and to perform builtin tests.

> As for the install, are you saying that running "ninja install"
> does not install lldb?  If so that's a bug and shoudl be fixed in
> the CMake.
> 

ninja/make install does its job installing LLDB properly.

My complain is that it's not possible (to my knowledge) to stop
installing Clang and LLVM sets.

I don't want to populate my system with the following example files:
bin/clang*
bin/llvm*
include/clang-c/
include/clang/
include/llvm/

Another good reason, besides time and space optimization is that among
others pkgsrc isn't designed to produce multiple packages from a
single meta-file (in a format of BSD Makefile in pkgsrc) with rules
specified to build a piece of software.

It's convenient to users to ship with separated prebuilt packages with
Clang, LLVM, LLDB etc. For now users who installed Clang from pkgsrc
won't be able to install LLDB from pkgsrc-wip (containing prebuilt
package with LLDB from HEAD/master/trunk of the debugger).

For now there seems to be need to go for walk-around similar to
ArchLinux [1]:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lldb-svn


Additionally I've optimized my build with
- -DLLVM_TARGETS_TO_BUILD="X86" and it significantly reduced the
resource usage! I will happily accept more suggestions how to tune it
further.

My current Makefile is here:
http://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f
=lldb-git/Makefile
GH mirror:
https://github.com/NetBSD/pkgsrc-wip/blob/master/lldb-git/Makefile


Thanks!

> On Sun, Nov 22, 2015 at 5:44 PM Kamil Rytarowski via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Are there plans to add new target: lldb-only and lldb-install?
> There are already similar targets for Clang.
> 
> I'm debugging LLDB on NetBSD and I'm having very bad time building 
> everything with debug symbols. There is also popular request from 
> NetBSD users to just install lldb without conflicting with Clang
> and LLV M.
> 
> I was looking at Open Source distributions with a LLDB package,
> for example ArchLinux is manually copying files from the build...
> 
> I would like to skip building unnecessary parts and then focus on 
> installing only the LLDB package... otherwise I need 64GB of 
> RAM+storage and a lot of time to produce new package. 
> ___ 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
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWUqBCAAoJEEuzCOmwLnZsywcP/iasACfyXiyRVE04J6HXmPxV
tvnnZp5WafPMmE2cp61oiivBO0PWBrG8aMeZelRZMPZPRhlvGIUYtwCe1W1CeeFq
QurYR7JwDcMA5fiVCmaqqToDQ3ki9J3fCmjvAnAKIHcq4+baXNDQOm2O3NvBBPNL
YHn2ZsKBWdZgIRvVYKx6o35zQYBOSgKqfPycvg7h+Nqvvb82MJIBmpb21SAHlbEz
hwBC/A2GxI399zxxb1vxicS8Fo7OUHx7pont6Er9mcPjLWvkRbahIWiPwysNR1is
I6HcRgyGSbbEMfuAbhZ16yHvq3Si79Si/O1DteJYF7+lrRdHqmStrQexPnx1E0zl
u1BrHWUiEkZq5dFHDID/30DQULF1baNq9/qmrVacChJluJlVMIyQwZz8GCXU0RXZ
cDwnmYSOxstUKWSeL7IvQ3aFMe0WCGXoeSQ0dH/JM0n8CKyVm2XWCAeYuGek7gor
BIzqIvE3AWll7+8lB7ehFKb0qRfFk1/wbriCcQNQxr92PCOFGAvy9GdD/o1NRFil
RuWSnJ9XOuhQ9oh9cwCWZqQ0oatX2HtXHNweRhpkLZLEFKYGA3tSyEse7ExQkcf7
qdAWK8i2uRDxsp/dfUEiMmZ+oqVOBPJ8WSC3ydurnr4eGqagf87/8XV+2u5XP1o5
sI2nL4XzxzcV4aMfzeIK
=BuOP
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/23/15 10:28, Pavel Labath wrote:
> I believe that for purposes of building distribution packages you 
> should use the out-of-tree mode of building lldb. This means, you 
> build llvm and clang separately, and then point your LLDB build to 
> their installation path with LLDB_PATH_TO_LLVM_BUILD and 
> LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid
> building llvm/clang twice, you can have a separate package for each
> logical component of llvm and you can make lldb optional for your
> users (e.g. have only clang installed normally, if user chooses to
> install lldb, it will automatically pull in clang if needed). In
> this mode "make install" should install only the lldb components,
> which should be correctly linked to the already-installed llvm
> libraries.
> 
> That said, I can't guarantee that this mode will work for you 
> out-of-the-box. We occasionally get patches to fix it up, but I
> don't know anyone who is using it extensively. However, I think
> this would be the best way forward for you and I'm prepared yo help
> you out if you choose to go that way.
> 
> What do you think about that?
> 
> pl
> 

Thank you for your note on this mode. I was trying to prototype a set
of packages with: sources of llvm and clang, build dirs of llvm and
clang and installations of llvm and clang.

Badly this approach doesn't work with pkgsrc, as this framework
contains various checks against using sources, headers, executables or
other files out of the build tree. Packaging sources and build tree
triggers errors with moving invalid files into ${DESTDIR}. Everything
is wolkaroundable, but I think it's not the correct way of handling it.

I've checked that libcxx, cfe and compiler-rt ship with mechanism to
build against preinstalled LLVM. I will try them out and I'm going to
prepare new pkgsrc packages using this approach. Then I will try to
research doing the same with LLDB, exporting needed libraries and
headers for the compiler withing llvm and lldb.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWV5xaAAoJEEuzCOmwLnZsgp4P/AwEFmITXpwolEfTkrGjaYIA
rRAqEkwkNjynN2vKEJYIZWOTxmFpjV/8bih8nCpWozirEAhssa7fD58D3cfO9wKT
8DLLf4bs4DCHfhWgbW9DDjkrjdevUOqAgte6bDN5toOwhNxR5RmCLfepWIpQ8HXj
4nGJ3DRl9CL4nZgO3WEGdkXI6xZY/55MmwXxQI9u5zU/RA+5iPmzm5iJIvMhyTNX
ULGJ1OgIBefj6XOfJ9CT7Y+l6vpv300m5uFmO4iqU9VbY5bQmyGf3CpDEYIteSXs
3axJ879pwv3kw9OoJC8ihOEYlk4aBjaGyoBflfGLS0Dk6ZikWk1jJ/qbPFapT0fA
rov2N+i1FS4+gApCo50ADQpkwCddvnmjNYo7/xNyFJLvKdODh/JxphmoiaG2gv68
QlkvZtAx53ahvD2M76nW2vZu9Mm3JEKd58uTkE36w6Res+xSuICuM2rirAMk9Xqp
28UZl2WhZcDCEAL+gmgxr84ThI9w/gRzqZ13I9Bifefim0V4bIrD+bhaodwlx3mI
j/YQpd2wZpwphzP7nnc+5ZBltpMgtuzI+CaJXpntONj4VUoPeVHrX4boPdczZAZx
JBNlKdXx0QHsOVUshbfK/Cz47oybnOEee0NE+4QlYVbkFXaYrB4Thu7OY5i+04Dd
UzBETcNz7IrnFpI7WjNv
=tiYf
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27.11.2015 00:57, Kamil Rytarowski via lldb-dev wrote:
> On 11/23/15 10:28, Pavel Labath wrote:
>> I believe that for purposes of building distribution packages you
>>  should use the out-of-tree mode of building lldb. This means,
>> you build llvm and clang separately, and then point your LLDB
>> build to their installation path with LLDB_PATH_TO_LLVM_BUILD and
>>  LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid 
>> building llvm/clang twice, you can have a separate package for
>> each logical component of llvm and you can make lldb optional for
>> your users (e.g. have only clang installed normally, if user
>> chooses to install lldb, it will automatically pull in clang if
>> needed). In this mode "make install" should install only the lldb
>> components, which should be correctly linked to the
>> already-installed llvm libraries.
> 
>> That said, I can't guarantee that this mode will work for you 
>> out-of-the-box. We occasionally get patches to fix it up, but I 
>> don't know anyone who is using it extensively. However, I think 
>> this would be the best way forward for you and I'm prepared yo
>> help you out if you choose to go that way.
> 
>> What do you think about that?
> 
>> pl
> 
> 
> Thank you for your note on this mode. I was trying to prototype a
> set of packages with: sources of llvm and clang, build dirs of llvm
> and clang and installations of llvm and clang.
> 
> Badly this approach doesn't work with pkgsrc, as this framework 
> contains various checks against using sources, headers, executables
> or other files out of the build tree. Packaging sources and build
> tree triggers errors with moving invalid files into ${DESTDIR}.
> Everything is wolkaroundable, but I think it's not the correct way
> of handling it.
> 
> I've checked that libcxx, cfe and compiler-rt ship with mechanism
> to build against preinstalled LLVM. I will try them out and I'm
> going to prepare new pkgsrc packages using this approach. Then I
> will try to research doing the same with LLDB, exporting needed
> libraries and headers for the compiler withing llvm and lldb.

For the cross reference.

A patch allowing to build (tested on NetBSD) out of sources pushed to
review: reviews.llvm.org/D15067
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWW96JAAoJEEuzCOmwLnZsCLAP/0LrhGlzivOjtykjW3ywvXia
wtZRLYsPwsNBJJERdOGVOJVPovnT02H+Bf1a4eDf0dJXbecklyfiupNfthlvFr9l
PxCLZI4GQPLcP+jqWbhcFRdhzFeyEnLLy0Wjt1MNYG0s3m2u4jJM2ViNLA10/kwS
XX82e2K7q5MUb51MMEJ09ufpYyGff7XmjVE78w1ekfNSRlKFMc0DNBsaIx4oKZfM
G2IUtRNL59ad2pkw/xA3D2OPtoTk7+a2jjF8Z4nYY6kUSyBPUlCYrjyfavVCreR6
6Zo2E3lkkEb6PSIfb57RlMtxBIfmIBjv5w6OcFjSK6aYvffY9IMgyBJvGbdA+Ee7
DlCFZax25eJPglEnfzAI2XOHOUQJtDwhb45N+XWshLfUax2e52KJvj9nq9J8pOse
AC00qRQN+KTZsil43dlOfEn5m18mJ9o+CohK5eLMoTnS9QdtP8OEv72zGjOsSqrx
vXDx01ziuQRCgsJ+niZXHgRLA65hxD5XgSGEBzr5prRLtU6q6V/HpYOsC46+pySc
ibLrRWHnaeBVJknwz11iBo4gBZRk3lGhi5aTfu9+kcX6ylKSn2nn34+HGHr//FZi
SrKcb3z7WikAR0c9cHBNOnwbro6o08j8zUE2l2S08risLRDDu01KBo3yFebjHz8D
vQqFJNDkRLywQbXezcjB
=7C7K
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02.12.2015 19:36, Jim Ingham wrote:
> Todd is right, at runtime lldb does need to find some of the clang
> include files in order to build modules for its own purposes.  On
> an OS X install, these headers are put in:
> 
> LLDB.framework/Resources/Clang
> 
> and are:
> 
>> ls
> ./avx512vlbwintrin.h  lzcntintrin.h   
> stdatomic.h ../
> avx512vlintrin.h  mm3dnow.h   stdbool.h Intrin.h  
> avxintrin.h
> mm_malloc.h   stddef.h __stddef_max_align_t.h bmi2intrin.h
> mmintrin.hstdint.h __wmmintrin_aes.h  bmiintrin.h
> module.modulemap  stdnoreturn.h __wmmintrin_pclmul.h  cpuid.h
> nmmintrin.h   tbmintrin.h adxintrin.h emmintrin.h 
> pmmintrin.h
> tgmath.h altivec.hf16cintrin.hpopcntintrin.h  
> tmmintrin.h 
> ammintrin.h   float.h prfchwintrin.h  
> unwind.h arm_acle.h
> fma4intrin.h  rdseedintrin.h  vadefs.h arm_neon.h 
> fmaintrin.h
> rtmintrin.h   varargs.h avx2intrin.h  ia32intrin.h
> shaintrin.h
> wmmintrin.h avx512bwintrin.h  immintrin.h smmintrin.h 
> x86intrin.h 
> avx512erintrin.h  iso646.hstdalign.h  
> xmmintrin.h avx512fintrin.h
> limits.h  stdarg.hxopintrin.h
> 
> Other than that, lldb shouldn't need to install any other clang
> bits for its own purposes - and on OS X at least lldb only installs
> itself and not any of the clang binaries, so in practice this can
> be made to work.
> 
> Also, building lldb requires a lot of clang/llvm headers that I
> don't think get installed in the normal course of things.  So I'm
> not sure how easy it is going to be to build lldb against an
> installed llvm/clang.  I couldn't tell for sure whether this was
> another of your goals, but it may take a fair bit of monkeying
> around if you want to do things this way.
> 

It seems that the only library / header out of public includes is for
handling raw (in C) Regular Expressions. I have a work-in-progress
code switching to public llvm::Regex instead. Other then that, there
are minor changes in CMake.

I'm ignoring autoconf framework since it's marked to be abandoned.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYN2hAAoJEEuzCOmwLnZsavoP/3sE59LBLSozwu5T9XOPh1oG
NpvpVFLvuyRgfb0JBEDQM/J13zbTTGSDl3A3IemvRA4Cvgeal34qKL4bsLSih3RF
fZ3699NAbmyFk92ePMIaLWFwmoiaBhboYHTR3sxiuhk0SHmPuK/PVuzD0xzPm4AC
AyqqdztkjTFZs5TyAg8vRJTlqY+VtPy4gcbG2DL0zECo1QRmsc+sFGkqmueYj7tc
5qgG7fcfswQ+gx5WFX652aksaep7ZsLpdgw3s9pFSdmAAu6PRo2CCXIYhllIHSPR
gdscSbI53LoNF5Z9ZWgDaYhEKkNKDlx9ib/zolUvNJfXuhm1yko2uPsis6XkVvBB
jsUbQ7VFLU+GYuHr6ys5qhHHEfTkAIhn9TZbhymJTt54eRPRONRmfaA6/PcZ3W+J
R/uJTNE9PvX9Hjhj2tV+59lSmrdlpmS6/9Akbv4lo3qkh2r4lJYVETpwlZv/IhJO
IHUcgdjVmFlmBC8p4nZhXxYLZiVjFT4sJr9JB/XZFkJWUajJNslIXr8hmhrzYnC1
ze71CXV4Z/q27KX3UeFmCcdudiviBA9IjzPhODknLVC60T+dIxI5C1yy1lfVnSx0
/FPurG255Eqg2sE2+DHUxIIJMfx2M8w4DrMCQAZEzO/hW+Ey05LH2fI43pcsduxF
SnkgZawyGkbQvn0NPI2M
=5u5p
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Compatibility with wide range of LLVM or Clang releases is out of scope.

On 02.12.2015 17:38, Todd Fiala wrote:
> Yes, that concept came out in the thread.  I just wanted to make
> sure there wasn't also a desire to park on a version of llvm/clang,
> and if so, that the path there is not pleasant and definitely not
> intended to be supported on top of tree svn/trunk.
> 
> Thanks for clarifying!
> 
> -Todd
> 
> On Wed, Dec 2, 2015 at 8:34 AM, Pavel Labath  > wrote:
> 
> On 2 December 2015 at 16:19, Todd Fiala  > wrote:
>> Sorry for being late the the party here.
>> 
>> Sean Callanan and some of the other members can comment more on
>> this, but LLDB's expression parser for C/C++ is going to need
>> access to the clang include headers, so somehow lldb has to be
>> able to find them.  Out of tree llvm/clang usage is certainly
>> possible as others have pointed out.  Using that as the one way
>> it is done, though, is likely to lead to pain.  Parts of lldb's
>> source will adjust as needed when the API surface area of LLVM
>> or clang changes.  It may not be happening quite as frequently as
>> it had say 2 or 3 years ago, but it definitely happens.  So my
>> expectation would be that if you decouple lldb from llvm/clang
>> (i.e. let them drift), sooner or later you will get bitten by
>> that.  Particularly when things like clang modules and whatnot
>> come along and actually require different logic on the lldb side 
>> to deal with content generated on the clang/llvm side.  Once
>> expression evaluation is potentially compromised (due to the
>> drift), I suspect the lldb experience will degrade
>> significantly.
> 
> I think you have misunderstood our intentions here.
> 
> Kamil, correct me if I am wrong, but I don't think we are talking 
> about building lldb against a different version of clang. What we
> want is just to be able to build and link lldb against an
> already-built clang (of the same version). This is quite useful
> when you (as a distribution maintainer) want to provide prebuilt
> packages. So, for example you can have a "clang" and an "lldb"
> package. Users wishing to install clang, just get the first one,
> while someone installing lldb will get the correct clang package
> pulled automatically. I believe the easiest way to build these
> packages is to use the standalone mode of lldb (which already
> exists, and some people use that).
> 
> hope that makes sense, pl
> 
> 
> 
> 
> -- -Todd

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYN6jAAoJEEuzCOmwLnZsdnsQAK7bn22uT/O61/QDF9oEYRlR
pzZtSkmGQZQuizw+TVUGgApk/KmwZ8BFsXUhguDzuDx8AR4qblYR+VwHSsQCaZwe
OIoZFTOOsmw5fBsbcYmtjlGsWOFQBWXOpMwXIZ5eQyQU8Q1rW2ssmniyfO7SkIE8
agcfzShyhzkFsQ9SLlHkZbNP+CALBVCOGWH4PnvdSkruIHKxmoOycgNvsG1HXsOV
jtgsx7S4EK1WEjPg3yzIiTgpYJVS2q3C2tLXmuYIg0TsNCwtoutSgodx6AV6Z31X
RbuDU8Gr4HqGZZa8LydRmoj2FRrkaMYEO2b8L9caQDRDCyn0TVEb6m5GSzut9EjP
+BKqeiNLaNVHIXjabsRf7a7tWpVSF0RH2vtyJOlXX1fisca4gWgpzLHY0u6IB37K
LnA4H1j/+f4ffOc1UpjFZs9Y6aTKLwAZaieZQXz8cRMueTpFBegla2osvY/Stg2f
OZnhzeUGcPVN2aERtR+HHxqWAZKHPHIPeTQTZ9vAEGF/KpedVrMEjgICCbisnLgQ
VNnm68m1aD8+30DNI70629JdmyjLGr5khzBmPipNqqZk8TB9Wn5HExTcSQod3fBP
+NHsaeucVcR0ZXL7vXM88yN28PRyHTGnVItAkSunsVCHwJ4WKtUyCHouSR2SMD2W
g0MvEbC3BKaPKRYB3WgB
=PHHJ
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB and Swift

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Very nice. Congrats on your release!

On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote:
> Hi all,
> 
> Earlier today, you may have heard that Swift went open source over 
> at swift.org .  I just wanted to take a moment
> to mention the Swift debugger and REPL and how they relate to
> LLDB.
> 
> Swift’s Debugger and REPL are built on LLDB’s source-level plug-in 
> architecture.  As such, the Swift Debugger repository at
> github.com/apple/swift-lldb 
> naturally contains the LLDB source from llvm.org
> ’s LLDB repository, plus additions for Swift
> language support. We merge regularly and make every attempt to 
> minimize our differences with llvm.org ’s LLDB.
> For more information on how we’re handling this, have a look at
> swift.org/contributing/#llvm-and-swift 
> .
> 
> As we’ve worked hard to make it straightforward to develop
> additive-only language support in LLDB, the Swift support can
> readily be found by finding the new files in the swift-lldb
> repository vs. those found at llvm.org/svn/llvm-project/lldb/trunk 
> .  For the rest of
> the LLDB files in common, we do still have a small number of diffs 
> in github.com/apple/swift-lldb 
> vs. llvm.org  TOT.  We will work through
> upstreaming these quickly.  I’ll touch on some of those differences
> briefly here:
> 
> * Several minor places where full language abstraction hasn’t yet 
> occurred, where we’re explicitly checking for Swift-related
> details. Abstracting out those remaining places and providing the
> hooks in llvm.org  LLDB will benefit all
> languages.
> 
> * Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) 
> version’ commands create a different version string in both Xcode
> and cmake-based Swift LLDB.  We will work to incorporate this into
> llvm.org  LLDB once the language/component
> version support info is properly abstracted out.
> 
> * Test infrastructure.  There are a few places where Swift
> language support (e.g. swift compiler flags, runtime support
> directories, etc.) are added in order to enable building
> Swift-based test inferiors.  We may be able to rearrange things to
> make those language-specific additions more readily pluggable in
> the core LLDB test runner.
> 
> We look forward to upstreaming the differences in common files in
> the coming days and weeks.
> 
> Please feel free to contact me if you have any questions.
> 
> Thanks!
> 
> -Todd
> 
> 
> ___ lldb-dev mailing
> list lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYOYqAAoJEEuzCOmwLnZsyVMP/0pC9Vahn0ErYFeBQoaXA3Qx
FFr7dAIMAyC+tH0Rb2virNLsrozgNXAnV06vfS2fdt1nB2sVwFDeZvtscjRCY0BC
w8v5N0joKb0Ao2RJcazCLJYOEihTc9thsBSQFDzQ3UIMJ5f5FIhykcSDecIh3OTQ
Hb2FGzTsFbdRLQvu6XwagaxT0n5PL3IG7BIRVLgQl988ICJvGNFDub7/7Ylee52b
oLtkxRhMMn9n2UXGPahQ6WozKfjc/l5s6isAp3bdkH4GEyTIv+D7/CKUmvLyZxaP
L75JS0g/bb++uMY+2naKzCrTYm7Se2hopIvbvgf7vkTIrLBUZt8JtJ7qkKkiwTL3
iW4oOiXUTz0pFQ6g2vdCGBM1263iPxS816JxLtW+aB4Gj/qhuzoTTseb7+KvFCVs
5PG87p7L6pm5TKswX+Cf6Di0O5fqyUFwk06hB9wuck6iCbT5dl4Zkty0OKsh/mnb
RSztbQn9BpCbMDiZe2wv5y8H8kaMvaNvnODqNdK6C94M4km6AD7YNx0WFMPkPrL5
IfLzGZau89ejrmJIU9SKW7HJRn+luIxjr2sa3BVGV+cZP4wUm9Z+d91Q6DPXwKv0
MBdb7ISPGqW13yYHYJ9dK/pKFjHiMFMjIzBsMvItqvN3Xy3GmHDIm80G6jzu7Wj0
VipucL5yeiHkTIJNccs8
=qRiS
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB/NetBSD test suite results as of 8 Dec 2015

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran the LLDB test suite of the LLDB-current version on NetBSD/amd64
(v. 7.99.21).

The results are as follows:

415 out of 415 test suites processed - TestRecursiveTypes.py

Ran 415 test suites (266 failed) (64.096386%)
Ran 222 test cases (145 failed) (65.315315%)
Failing Tests (266)

The major missing piece is native process tracking support (with the
ptrace(2) interface). Once added, LLDB should start to be usable on
this platform.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWZiQdAAoJEEuzCOmwLnZsHNUQALe8F61h9fSyaw0l6nWOIpHs
THgeCWPKMWsf4z82wb4kFWY6TKroUkzl4BiizBUMs+m3fMJLSOMuTp6/kOCOiXM7
DyRbCkVqXOn/qXg8rocf/mpYmxDRyWM+GcNmwCY/lXp6eYmB67PN4ymxb5mpc1z1
27L//+BsKW+EoGT5diTyDzVgpb9U2MZk2nR4lbimuJpmhzEgtFiMLT7GX6BCwoAA
IWCMmO6FKiE5e5PiDoH8j+stMD5+NN2K6l6rS7JrTPdi0TwGSkIH8/DJL5Nob0lv
lyr74B9vVIbsNk4gjzdOgOBOPIt8OVPL4m2GtBQcrCXNbsh88EZnUT+jIHCe3XjT
p8lyrwVrzJBtijlYHJjbyRBzJtUoJ0fVFEiKI/S9Wdki77sQ1Mz48Mfa/+hgrnuW
oc/qUyeNTTj9chjd3NpTQht5H3IF8xDIjqLmLdnYgDwnsZFd8BhHz3QGqbbP0Aa8
jNy2NCF0+Gog1tF6xSOhBINXFF8qZJOiDOZleUc95wTz+Aw/0NLNqkq9JqPB0s6t
KDM/ykNA0MtJD2b9u8tOFDqVQTJQdiwTKpg6BfdBxBE0R4O9zxb2XjP5fylU+y7Y
TywBSauQ0UnqAe/nXCtWFHFEpzzuNt0D4RWzlO25WaehVbrbC+DyNuC9IKufYiGp
uVIOFiM8loMJFCiQm+DL
=Egm3
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD test suite results as of 8 Dec 2015

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08.12.2015 17:21, Ed Maste wrote:
> On 7 December 2015 at 19:28, Kamil Rytarowski via lldb-dev 
>  wrote:
>> 
>> I ran the LLDB test suite of the LLDB-current version on
>> NetBSD/amd64 (v. 7.99.21).
>> 
>> The results are as follows:
>> 
>> 415 out of 415 test suites processed - TestRecursiveTypes.py
>> 
>> Ran 415 test suites (266 failed) (64.096386%) Ran 222 test cases
>> (145 failed) (65.315315%) Failing Tests (266)
>> 
>> The major missing piece is native process tracking support (with
>> the ptrace(2) interface). Once added, LLDB should start to be
>> usable on this platform.
> 
> Great progress, and thanks for the update! Are you planning to
> base the NetBSD native support on NativeProcessLinux? I need to
> migrate the FreeBSD support to work that way still.
> 


In my initial scratch (before upstreaming of the current NetBSD
support) I cloned the current FreeBSD approach. It was halfbaked,
building and not working.

I will see the NativeProcessLinux way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWaJMmAAoJEEuzCOmwLnZs9PEP/ieCtuUqDE+G9hDm3sk4u4I+
83aMdtOzWFO4I26MLRjqKqytn5iEgltWuLT0VW47IU/hynkEOET8m3cwTLkIakGC
pBohk16yl6dQo97rU3/dVlLuKpkuN1wk19/IRxbqVSV8m86IFAPI1T8xQCWXa9iT
6dTRli4pW0OemlBxvWXM0tRm7d2GISgkAlGbHkZ3grfQYufJ8ulZyGDI+5Kss0oV
Ku0ovL9U+vtyLdHlcpimuTaMvMZThnv3eJdImGlwXJrvS4yZifP2PiyM3qGXxiqb
0ZzBT9Gb8fqVoVOD9Al95NycIHu/jptudt+3YJoeMN903eQz6wT7izZm055MpEfu
HPKvrbpeQyOZ2j7Z8xbqlNl0vm0Q2c41/LaoneMOcf6Uu7XZ/5yaKT+j2oGT6O4m
vRZ3pfyZqlTMtlUxs6+HfFT08AfW1cRqmpNInw/fkQVtmmIkytmOELF/fpsks8XC
cXF3XQtFRGmbDyvGZdeKwXO55qCyL9w3BbhMTrIopm+sPaayB4OcGnV00++3mwJn
Y3iUXTb5Xrqm1ORFUaXmaoDdiSSSHhAZRmS+VgqJ4/+AWWiWcGbZd2oKIg3b+FmO
yu1DIeFsmWnaFNkp+cjnjr049ofO8kUbr6dCIJ6EyiydRWwXLufiKZhpYmpT48i1
kenLjLCuVTYFjkzM8HXA
=0zUx
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Interest in enabling -Werror by default

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

NetBSD builds with GCC 4.8.2 and it emits few warnings for LLDB.

Before enabling -Werror please first iterate over build logs and help
to squash them. For example it detects undefined behavior IIRC for a
Darwin code part.

On 16.02.2016 20:01, Zachary Turner via lldb-dev wrote:
> You're talking about doing it on a per-bot basis and not a global 
> policy, but just throwing in that on the MSVC side at least, we're
> not warning free right now and it's not trivial tog et warning free
> without disabling some warnings (which I don't want to do either)
> 
> On Tue, Feb 16, 2016 at 10:31 AM Saleem Abdulrasool via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> On Tuesday, February 16, 2016, Tamas Berghammer 
> mailto:tbergham...@google.com>> wrote:
> 
> If you want to enable it only on the bots then I think we can 
> decide it on a bot by bot bases. For me the main question is who 
> will be responsible for fixing a warning introduced by a change in
> llvm or clang causing a build failure because of a warning 
> (especially when the fix is non trivial)?
> 
> 
> I think that the same policy as LLVM/clang should apply here.  The 
> person making the change would be responsible for ensuring that 
> nothing breaks as a result of their change.  The same situation 
> exists when working on interfaces that effect clang: a fix for a 
> warning introduced by a change in LLVM may be non-trivial in
> clang.
> 
> Just to be clear, I'm merely suggesting this as an option.  If it
> is deemed too burdensome by most of the common committers, we state
> so and not do this.
> 
> 
> 
> On Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool 
>  wrote:
> 
> On Tuesday, February 16, 2016, Tamas Berghammer 
>  wrote:
> 
> I would be happy if we can keep lldb warning free but I don't think
> enabling -Werror is a good idea for 2 reasons: * We are using a lot
> of different compiler and keeping the codebase warning free on all
> of them might not be feasible especially for the less used, older
> gcc versions. * Neither llvm nor clang have -Werror enabled so if
> we enable it then a clang/llvm change can break our build with a
> warning when it is hard to justify a revert and a fix might not be
> trivial.
> 
> 
> Err, sorry.  I meant by default on the build bots (IIRC, some
> (many?) of the build bots do build with -Werror for LLVM and
> clang).  Yes, a new warning in clang could cause issues in LLDB,
> though the same thing exists for the LLVM/clang dependency.  Since
> this would be on the build bots, it should get resolved rather
> quickly.
> 
> In short term I would prefer to just create a policy saying
> everybody should write warning free code for lldb (I think it
> already kind of exists) and we as a community try to ensure it
> during code review and with fixing the possible things what slip
> through. In the longer term I would be happy to see -Werror turned
> on for llvm and clang first and then we can follow up with lldb but
> making this change will require a lot of discussion and might get
> some push back.
> 
> On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev
>  wrote:
> 
> Hi,
> 
> It seems that enabling -Werror by default is within reach for lldb
> now.  There currently are three warnings that remain with gcc 5.1
> on Linux, and the build is clean of warnings with clang.
> 
> There are two instances of type range limitations on comparisons in
> asserts, and one instance of string formatting which has a GNU
> incompatibility.
> 
> Is there any interest in enabling -Werror by default to help keep
> the build clean going forward?
> 
> -- Saleem Abdulrasool compnerd (at) compnerd (dot) org 
> ___ lldb-dev mailing
> list lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
> 
> 
> 
> -- Saleem Abdulrasool compnerd (at) compnerd (dot) org 
> ___ 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
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWw4isAAoJEEuzCOmwLnZsR+kP/iCRzeJSzPFvjUZ9zwIz5HBo
6i+hoaxHzSOy0PS7936KiaIhlvm5zumFEBKZcrWvTAdnR8aIAPqpSFUp95LGHX6A
LDrE/pXlXXjCHelKeqlfqcFoxg0Jwl4UzvEL0M5PhEAykPs/K9/CXIAvOZNi/lue
UcYPxZpM+4cNoTFIm7MdvQAD3MwO1QTA0qkXIKiBT5WeKbHGOlEP0mrrpJSp2aUl
a+2fodZGr38HqHsQ5LGLVsBQsXmisvsuwAtQodGj3WuI+75r6wko/F7QdRh1sXAB
nC4Lan0BX23ji38wVse4Z4iRUpXcWCTZgf+/TcjfPuog37Ay95WuKurou8b3BFvn
LFBSMhcs3L/RiBArjvklymvEQlUwKaZ4G09Audxxpi8HvGfNFMeTqSI+Dvz/wAC7
9M7BoJpbE67pF1ZaUcQx36ULFzMxNzAdSoEeNKHUsS0uftzMg0RFxRDFY3THEbc5
cVLknKznHWCGwLCT6DCw2+a+rkLZNlViwTjFNyReBYNZ0+7kG6eG0SmwZjAa2Ip3
0X9YI0

[lldb-dev] Redundant six.py copy

[Kamil Rytarowski via lldb-dev]

It has been noted that LLDB installs its own copy of six.py
(third_party/Python/module/six/six.py) that conflicts with a standalone
one lang/py-six (path in pkgsrc).

Could we reuse an external version shipped with a system? Alternatively
are there plans to migrate to Python 3 and remove need for it?

How to address this conflict cleanly?



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Redundant six.py copy

[Kamil Rytarowski via lldb-dev]

There are currently 83 packages that require py-six in pkgsrc [1] and
changes for a conflict are high, unless someone is using a bare system
with a minimal set of packages.

I'm looking for a solution that is applicable upstream and isn't
patching the sources downstream. Can other users install py-six in their
systems with their python installations?

[1] http://pkgsrc.se/dependon.php?path=lang/py-six&branch=CURRENT

On 02.05.2016 00:35, Zachary Turner wrote:
> Six isn't a module that is normally installed. I think the pythonic way
> to do this is tell people "you need to install six before you can use
> lldb", but given the number of different ways in which people use it and
> the different needs, this isn't ideal.
> 
> There are no plans to drop support for 2.7, so it will continue to be
> needed. Do you actually get an error?
> On Sun, May 1, 2016 at 2:22 PM Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> It has been noted that LLDB installs its own copy of six.py
> (third_party/Python/module/six/six.py) that conflicts with a standalone
> one lang/py-six (path in pkgsrc).
> 
> Could we reuse an external version shipped with a system? Alternatively
> are there plans to migrate to Python 3 and remove need for it?
> 
> How to address this conflict cleanly?
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Redundant six.py copy

[Kamil Rytarowski via lldb-dev]

On 02.05.2016 18:40, Reid Kleckner wrote:
> On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
> It has been noted that LLDB installs its own copy of six.py
> (third_party/Python/module/six/six.py) that conflicts with a
standalone
> one lang/py-six (path in pkgsrc).
>
> Could we reuse an external version shipped with a system?
Alternatively
> are there plans to migrate to Python 3 and remove need for it?
>
> How to address this conflict cleanly?
>
>
> LLDB should continue to ship its own copy of six.py. It's a single 900
> line source file. Avoiding this duplication is not worth the headache of
> asking users to install dependencies. I can't imagine a world where
> checking in your own copy *wasn't* the intended distribution model for
> six.py.
>

I don't agree here, built in libraries have security and maintainability
issues downstream. Correct packaging is about removing these builtin
redundant libraries and link with upstream ones. And in case of a
vulnerability (or other kind of bug) upgrade a dependency for everybody
at once.

> I'm sure LLDB would take patches to mitigate the namespace conflict. For
> example, LLDB could do something like "from lldbutils import six"
> instead of "import six", or we could avoid putting it on sys.path if we
> notice a system installation of six.

Dynamic detection of system capabilities isn't reproducible. Also there
is a scenario of installing lldb and later one of other packages
installing global py-six.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Redundant six.py copy

[Kamil Rytarowski via lldb-dev]

Having private fallback six.py will work for everybody, just it cannot
be installed into the global path along with Python libraries:

$ pkg_info -L lldb|grep six.py
/usr/pkg/lib/python2.7/site-packages/six.py

Maybe in lldb/utils/?

chieftec$ pkg_info -L lldb|grep py
/usr/pkg/lib/python2.7/site-packages/lldb/__init__.py
/usr/pkg/lib/python2.7/site-packages/lldb/_lldb.so
/usr/pkg/lib/python2.7/site-packages/lldb/embedded_interpreter.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/Logger.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/__init__.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/attrib_fromdict.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/cache.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/__init__.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/gnu_libstdcpp.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/libcxx.py
/usr/pkg/lib/python2.7/site-packages/lldb/formatters/metrics.py
/usr/pkg/lib/python2.7/site-packages/lldb/lldb-argdumper
/usr/pkg/lib/python2.7/site-packages/lldb/runtime/__init__.py
/usr/pkg/lib/python2.7/site-packages/lldb/utils/__init__.py
/usr/pkg/lib/python2.7/site-packages/lldb/utils/symbolication.py
/usr/pkg/lib/python2.7/site-packages/six.py

On 03.05.2016 02:13, Greg Clayton via lldb-dev wrote:
> Can we take care of this with python include path ordering? If we are on a 
> system that has its own six.py somewhere in the python libraries, how is it 
> picking our version incorrectly? Aren't there search paths for the modules? 
> If so, we might need to put any compatibility modules into a specific 
> directory and add that to the python search paths as the last path so it 
> would always pick up any system versions or installed versions first, then 
> fall back to our extra ones in our directories.
> 
> Greg
> 
>> On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev 
>>  wrote:
>>
>> This may be true, but telling my users "you have to install six" is a 
>> non-starter.
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>
>>> -----Original Message-
>>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Kamil
>>> Rytarowski via lldb-dev
>>> Sent: Monday, May 02, 2016 4:36 PM
>>> To: Reid Kleckner 
>>> Cc: LLDB 
>>> Subject: Re: [lldb-dev] Redundant six.py copy
>>>
>>>
>>>
>>> On 02.05.2016 18:40, Reid Kleckner wrote:
>>>> On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>
>>>>It has been noted that LLDB installs its own copy of six.py
>>>>(third_party/Python/module/six/six.py) that conflicts with a
>>> standalone
>>>>one lang/py-six (path in pkgsrc).
>>>>
>>>>Could we reuse an external version shipped with a system?
>>> Alternatively
>>>>are there plans to migrate to Python 3 and remove need for it?
>>>>
>>>>How to address this conflict cleanly?
>>>>
>>>>
>>>> LLDB should continue to ship its own copy of six.py. It's a single 900
>>>> line source file. Avoiding this duplication is not worth the headache
>>>> of asking users to install dependencies. I can't imagine a world where
>>>> checking in your own copy *wasn't* the intended distribution model for
>>>> six.py.
>>>>
>>>
>>> I don't agree here, built in libraries have security and maintainability 
>>> issues
>>> downstream. Correct packaging is about removing these builtin redundant
>>> libraries and link with upstream ones. And in case of a vulnerability (or 
>>> other
>>> kind of bug) upgrade a dependency for everybody at once.
>>>
>>>> I'm sure LLDB would take patches to mitigate the namespace conflict.
>>>> For example, LLDB could do something like "from lldbutils import six"
>>>> instead of "import six", or we could avoid putting it on sys.path if
>>>> we notice a system installation of six.
>>>
>>> Dynamic detection of system capabilities isn't reproducible. Also there is a
>>> scenario of installing lldb and later one of other packages installing 
>>> global py-
>>> six.
>>
>>
>> ___
>> 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
> 



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Push work-in-progress plugin for Process NetBSD?

[Kamil Rytarowski via lldb-dev]

I keep locally almost 5k lines of code of the process plugin for NetBSD.

It's still not functional (there are bugs), but it has all or mostly all
of the code needed for amd64. Is it fine to push it upstream and
continue development against the version in-tree?

My code is based on FreeBSD with removed unsupported features, missing
in the current version of NetBSD.

It will be easier for me to keep it in sync with HEAD and should be
usable for other teams to take it into account in further changes.


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

Re: [lldb-dev] Standalone build broken after r269332

[Kamil Rytarowski via lldb-dev]

On 14.05.2016 02:46, Eugene Zelenko via lldb-dev wrote:
> But biggest problem remains is how to specify Clang source and build
> directories, since llvm-config doesn't tells about them.

The requirement of source-code of Clang+LLVM and build dirs of Clang and
LLVM is no-go in a package-manager use-case. This is only needed for the
import of regex implementation pulled out of LLDB sources.

The proper fix for it is to stop using regex implementation from out of
the LLDB sources.

Temporarily, I'm building LLDB on NetBSD with a local patch [1] adding
these regex libraries without any further issues in the standalone
build. In order to work on proper regex usage in LLDB, I need to
increase the number of passed tests on my platform -- to catch any
regressions easier.

[1] https://github.com/NetBSD/pkgsrc-wip/tree/master/lldb-git/patches
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB targeting NetBSD-8.0

[Kamil Rytarowski via lldb-dev]

I'm moving my efforts of porting LLDB from NetBSD-7.0 to NetBSD-8.0.

I decided that 7.0 isn't worth more effort since libstdc++ is already
too old (no ) and it misses support for debug registers and
useful ptrace(2) interfaces for a full-process instrumentation.

I'm going to upgrade the LLVM+Clang+LLDB buildbot to NetBSD HEAD (pre 8.0).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Standalone build broken after r269332

[Kamil Rytarowski via lldb-dev]

In further changes please add me to review, I will test the standalone
build.

Yes, I'm running an installed version of llvm-config and I don't have
sources neither build files.

On 17.05.2016 10:05, Pavel Labath via lldb-dev wrote:
> Ok, I see what the problem is now. If you run llvm-config from the
> build folder, it will print out the correct path for the llvm headers,
> but this will not be correct for the clang headers as it points
> directly to the subfolder of the source llvm checkout. In Kamil's use
> case this will be fine since he is presumably running an installed
> llvm-config, in which case it ends up pointing us to the installed
> headers under /usr/lib, and if you install clang to the same location
> everything is fine.
> 
> So, it sounds to me like we should resurrect the CLANG_BUILD and
> CLANG_SOURCE (a poor man's version of clang-config) variables that got
> removed. There should be no need for the LLVM vars, as llvm-config
> should cover that, right? Can you prepare a patch for that?
> 
> pl
> 
> On 17 May 2016 at 00:36, Eugene Zelenko via lldb-dev
>  wrote:
>> Hi, Pavel!
>>
>> On Mon, May 16, 2016 at 3:04 AM, Pavel Labath  wrote:
>>> Hi Eugene,
>>>
>>> my thoughts on this are inline.
>>>
>>> At which stage does the build now fail for you (after applying the
>>> fixes above)?
>>
>> Build failed at very beginning:
>>
>> source/lldb.cpp:19:10: fatal error: 'clang/Basic/Version.h' file not found
>>
>> But there are much more places which depends on Clang headers (AST, Basic).
>>
>>> As Kamil said, LLDB really shouldn't depend on the clang source
>>> folder. The only dependency I know of is the uglyness in lldb-mi, but
>>> it looks like it should be easy to fix (basically, lldb-mi should use
>>> the public regex interface instead of the private one, porting
>>> appeared straight-forward), so I think someone should just bite the
>>> bullet and do it. If you need any more changes after that, we can look
>>> into that then.
>>
>> I build LLVM/Clang/ect with LLVM_INSTALL_TOOLCHAIN_ONLY=ON, so source
>> and build directories are needed for headers and libraries. I try to
>> save disc space for final installation and we don't use LLVM/Clang
>> headers/libraries internally, so source and build directories were
>> good enough for us.
>>
>> Eugene.
>> ___
>> 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] How to link lldb on i386

[Kamil Rytarowski via lldb-dev]

I had similar problems on NetBSD/amd64 - using standalone builds helped
me. I'm building and installing LLVM, Clang and LLDB separately. It may
help on i386.

Also there might be a problem with using too many jobs. Try to build
with -j1.

On 24.05.2016 20:01, Siva Chandra via lldb-dev wrote:
> We hit similar problems in the past when building with debug info
> enabled; using -gsplit-dwarf helped us.
> 
> On Sun, May 22, 2016 at 3:36 AM, Sylvestre Ledru via lldb-dev
>  wrote:
>> Hello,
>>
>> Lately, I haven't been able to link lldb because it uses too much memory:
>>
>> /usr/bin/ld: final link failed: Memory exhausted
>>
>> As reported here:
>> https://llvm.org/bugs/show_bug.cgi?id=27237
>>
>> (yes, I use shared libraries)
>>
>> Any workaround?
>>
>> Thanks,
>> Sylvestre
>> PS: please cc me !
>>
>>
>> ___
>> 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] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

[Kamil Rytarowski via lldb-dev]

On 24.05.2016 22:54, Chris Bieneman via lldb-dev wrote:
> Meant to send this yesterday, but I want to remind everyone that we’re going 
> to be raising the CMake minimum version to 3.4.3 next week.
> 
> If you maintain bots please ensure that your bots are updated by end of day 
> 5/29 so that we can move on 5/30 (next Monday).
> 
> I have already heard from most bot owners either saying they had made the 
> change, or scheduled to make it.
> 
> If you have any questions or concerns please let me know.
> 
> Thank you,
> -Chris
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

3.4.3 in LLDB? Lately we moved to 2.8.12.2 in the CMakeLists.txt files.

netbsd7 currently runs with cmake-3.3.1, I will update during the weekend.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] netbsd7 buildbot broken

[Kamil Rytarowski via lldb-dev]

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/4296

It looks like after this build, scripts for bots were altered to require
clang + clang++? I'm using the GNU toolchain. Could we please revert
this enforcement?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] netbsd7 buildbot broken

[Kamil Rytarowski via lldb-dev]

There is a change in build scripts from buildbot farm:

+ cmake -GNinja -DCMAKE_BUILD_TYPE=Release
/home/motus/build/build/scripts/../llvm -DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++

A commit earlier it was:

+ cmake -GNinja -DCMAKE_BUILD_TYPE=Release
/home/motus/build/build/scripts/../llvm -DCMAKE_C_COMPILER=gcc
-DCMAKE_CXX_COMPILER=g++ -DLLDB_DISABLE_CURSES:BOOL=FALSE

On 25.05.2016 02:22, Zachary Turner wrote:
> There's no CMake change in any of these patches.  It looks like
> something is wrong with your bot.
> 
> On Tue, May 24, 2016 at 5:14 PM Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/4296
> 
> It looks like after this build, scripts for bots were altered to require
> clang + clang++? I'm using the GNU toolchain. Could we please revert
> this enforcement?
> ___
> 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

Re: [lldb-dev] netbsd7 buildbot broken

[Kamil Rytarowski via lldb-dev]

It's now clear. Thank you!

On 25.05.2016 11:30, Pavel Labath wrote:
> I modified those scripts recently (it's these scripts
> <https://android.googlesource.com/platform/external/lldb-utils/+/lldb-master-dev/buildbotScripts/bashShell/svntotbuild/>,
> for those who don't know what we are talking about), and I
> accidentally broke that. I am sorry about that, it should be fixed
> now.
> 
> However, I'd like to take this opportunity to make some things clear:
> - these scripts are not a part of the llvm infrastructure, so mailing
> Galina or lldb-dev about problems with them will not help as they
> don't have the ability to change them. For issues with them, you will
> need to contact someone on the android team (me, Tamas, Oleksiy).
> - we don't mind you or anyone else using those scripts, but we provide
> no SLA for them. We may (and we do) change the scripts at will and we
> reserve the right to change them in any way, including ways which make
> it incompatible with other buildbots. (This sounds harsh, we don't
> intend to do that any time soon. However, the point is that we want to
> have the flexibility in managing our buildbots.)
> 
> With the above in mind I'd suggest that you investigate alternative
> approaches to managing your buildbot. I recommend creating a random
> github repo and sticking the scripts there, so you have the ability to
> manage them as you see fit (feel free to make a copy of the current
> scripts).
> 
> cheers,
> pl
> 
> 
> 
> On 25 May 2016 at 05:58, Kamil Rytarowski via lldb-dev
>  wrote:
>> There is a change in build scripts from buildbot farm:
>>
>> + cmake -GNinja -DCMAKE_BUILD_TYPE=Release
>> /home/motus/build/build/scripts/../llvm -DCMAKE_C_COMPILER=clang
>> -DCMAKE_CXX_COMPILER=clang++
>>
>> A commit earlier it was:
>>
>> + cmake -GNinja -DCMAKE_BUILD_TYPE=Release
>> /home/motus/build/build/scripts/../llvm -DCMAKE_C_COMPILER=gcc
>> -DCMAKE_CXX_COMPILER=g++ -DLLDB_DISABLE_CURSES:BOOL=FALSE
>>
>> On 25.05.2016 02:22, Zachary Turner wrote:
>>> There's no CMake change in any of these patches.  It looks like
>>> something is wrong with your bot.
>>>
>>> On Tue, May 24, 2016 at 5:14 PM Kamil Rytarowski via lldb-dev
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/4296
>>>
>>> It looks like after this build, scripts for bots were altered to require
>>> clang + clang++? I'm using the GNU toolchain. Could we please revert
>>> this enforcement?
>>> ___
>>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3

[Kamil Rytarowski via lldb-dev]

NetBSD is ready (cmake-3.5.2).

It now runs 7.0 kernel, 7.99.29 userland and newer GNU toolchain (GCC
5.3, LD 2.26).

http://lab.llvm.org:8011/buildslaves/lldb-amd64-ninja-netbsd7

On 26.05.2016 18:57, Zachary Turner via lldb-dev wrote:
> Windows LLDB is done
> 
> On Thu, May 26, 2016 at 2:39 AM Daniel Sanders via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> All the MIPS buildbots are ready too.
> 
> __ __
> 
> *From:*llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org
> ] *On Behalf Of *NAKAMURA
> Takumi via llvm-dev
> *Sent:* 25 May 2016 23:03
> *To:* Chris Bieneman; llvm-...@lists.llvm.org
> ; cfe-...@lists.llvm.org
> ; lldb-dev@lists.llvm.org
> 
> *Subject:* Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum
> version to 3.4.3
> 
> __ __
> 
> I am ready, regarding to, http://bb.pgr.jp/ 
> 
> On Wed, May 25, 2016 at 5:54 AM Chris Bieneman  > wrote:
> 
> Meant to send this yesterday, but I want to remind everyone that
> we’re going to be raising the CMake minimum version to 3.4.3
> next week.
> 
> If you maintain bots please ensure that your bots are updated by
> end of day 5/29 so that we can move on 5/30 (next Monday).
> 
> I have already heard from most bot owners either saying they had
> made the change, or scheduled to make it.
> 
> If you have any questions or concerns please let me know.
> 
> Thank you,
> -Chris
> 
> ___
> 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] [OS X]: building lldb with cmake

[Kamil Rytarowski via lldb-dev]

On 09.09.2016 10:55, René J.V. Bertin via lldb-dev wrote:
> Hi,
> 
> I've been working on a MacPorts port for lldb
> 

There is already available framework with standalone build of LLDB for
Darwin -- pkgsrc. So far it ships with local patches, but they are being
eliminated.

http://pkgsrc.se/devel/lldb



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Build failure with llvm/IR/Attributes.gen?

[Kamil Rytarowski via lldb-dev]

It's still broken for NetBSD

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/6775

On 30.09.2016 01:04, Chris Bieneman via lldb-dev wrote:
> Hal, thanks for the heads up. I just committed a patch that should resolve 
> this in r282803.
> 
> Thanks!
> -Chris
> 
>> On Sep 29, 2016, at 1:49 PM, Hal Finkel  wrote:
>>
>> - Original Message -
>>> From: "Hal Finkel via lldb-dev" 
>>> To: lldb-dev@lists.llvm.org
>>> Sent: Thursday, September 29, 2016 2:51:03 PM
>>> Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
>>>
>>> Hi everyone,
>>>
>>> Starting a few days ago (between Sept 22nd and 23rd) my nightly
>>> builds including lldb starting failing:
>>>
>>> In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0,
>>> from /path/to/llvm/include/llvm/IR/Function.h:22,
>>> from /path/to/llvm/include/llvm/IR/Module.h:21,
>>> from
>>> 
>>> /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22,
>>> from
>>> 
>>> /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12:
>>> /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error:
>>> llvm/IR/Attributes.gen: No such file or directory
>>> #include "llvm/IR/Attributes.gen"
>>>  ^
>>> compilation terminated.
>>>
>>> This might be simply the result of some unexpressed dependency in the
>>> cmake files (my build uses make -j72, so it tends to find these
>>> kinds of issues when they come up). Any ideas?
>>
>> [+Chris B.]
>>
>> Doing this seems to help:
>>
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> index 85d4b51..9615a3c 100644
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen)
>> # an entire module might include header, which depends on intrinsics_gen. 
>> This
>> # should be right after LLVMSupport and LLVMTableGen otherwise we introduce a
>> # circular dependence.
>> -if (LLVM_ENABLE_MODULES)
>> +#if (LLVM_ENABLE_MODULES)
>>   list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
>> -endif(LLVM_ENABLE_MODULES)
>> +#endif(LLVM_ENABLE_MODULES)
>>
>> add_subdirectory(include/llvm)
>>
>> but that does not seem like a real solution.
>>
>> -Hal
>>
>>>
>>> Thanks again,
>>> Hal
>>>
>>> --
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>> -- 
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
> 
> ___
> 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] Build failure with llvm/IR/Attributes.gen?

[Kamil Rytarowski via lldb-dev]

It works now, thank you!

On 03.10.2016 02:15, Chris Bieneman wrote:
> This is a different missing dependency. I've committed r283081 to fix
> this one and another one that I found. Hopefully that should get things
> working.
> 
> -Chris
> 
> On Oct 2, 2016, at 5:39 AM, Kamil Rytarowski  > wrote:
> 
>> It's still broken for NetBSD
>>
>> http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/6775
>>
>> On 30.09.2016 01:04, Chris Bieneman via lldb-dev wrote:
>>> Hal, thanks for the heads up. I just committed a patch that should
>>> resolve this in r282803.
>>>
>>> Thanks!
>>> -Chris
>>>
 On Sep 29, 2016, at 1:49 PM, Hal Finkel >>> > wrote:

 - Original Message -
> From: "Hal Finkel via lldb-dev"  >
> To: lldb-dev@lists.llvm.org 
> Sent: Thursday, September 29, 2016 2:51:03 PM
> Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
>
> Hi everyone,
>
> Starting a few days ago (between Sept 22nd and 23rd) my nightly
> builds including lldb starting failing:
>
> In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0,
>from /path/to/llvm/include/llvm/IR/Function.h:22,
>from /path/to/llvm/include/llvm/IR/Module.h:21,
>from
>
> /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22,
>from
>
> /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12:
> /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error:
> llvm/IR/Attributes.gen: No such file or directory
>#include "llvm/IR/Attributes.gen"
> ^
> compilation terminated.
>
> This might be simply the result of some unexpressed dependency in the
> cmake files (my build uses make -j72, so it tends to find these
> kinds of issues when they come up). Any ideas?

 [+Chris B.]

 Doing this seems to help:

 diff --git a/CMakeLists.txt b/CMakeLists.txt
 index 85d4b51..9615a3c 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen)
 # an entire module might include header, which depends on
 intrinsics_gen. This
 # should be right after LLVMSupport and LLVMTableGen otherwise we
 introduce a
 # circular dependence.
 -if (LLVM_ENABLE_MODULES)
 +#if (LLVM_ENABLE_MODULES)
  list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen)
 -endif(LLVM_ENABLE_MODULES)
 +#endif(LLVM_ENABLE_MODULES)

 add_subdirectory(include/llvm)

 but that does not seem like a real solution.

 -Hal

>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

 -- 
 Hal Finkel
 Lead, Compiler Technology and Programming Languages
 Leadership Computing Facility
 Argonne National Laboratory
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] NetBSD buildbot new machine

[Kamil Rytarowski via lldb-dev]

Hello,

I'm in process of switching a machine for NetBSD buildbot. It will be
temporarily unavailable.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] NetBSD buildbot new machine

[Kamil Rytarowski via lldb-dev]

New machine is up and running.

There is more power and it builds the whole distribution within 35 minutes.

On 04.10.2016 15:13, Kamil Rytarowski via lldb-dev wrote:
> Hello,
> 
> I'm in process of switching a machine for NetBSD buildbot. It will be
> temporarily unavailable.
> 
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

[Kamil Rytarowski via lldb-dev]

On 24.10.2016 20:38, Ed Maste wrote:
> On 24 October 2016 at 06:26, Pavel Labath  wrote:
>>
>> It's not my place to tell you how to work, but I'd recommend a
>> different approach to this. If you base your work on the current
>> FreeBSD in-process plugin, then when you get around to actually
>> implementing remote support, you will find that you will have to
>> rewrite most of what you have already done to work with lldb-server,
>> as it uses completely different class hierarchies and everything. I'd
>> recommend starting with lldb-server right away. It's going to be a bit
>> more work as (I assume) freebsd implementation is closer to what you
>> need than linux, but I think it will save you time in the long run. I
>> can help you with factoring out any linux-specific code that you
>> encounter.
> 
> I definitely second the approach Pavel suggests here, and am happy to
> work with others on refactoring the Linux lldb-server so that we can
> get it to support both FreeBSD and NetBSD at the same time.
> 
> A direct port of the current FreeBSD support probably would result in
> a basic level of support running sooner, but that work would be
> largely thrown away in a future migration to lldb-server.
> 

I will take your recommended path as it will lead to the same goal.

I will try to shorten my initial work on ptrace(2) leaving additional
features+tests for later and jump to lldb-server as soon as possible.

For start, before switching to process plugin stage is to extend NetBSD
ptrace(2) with the following features:

 - PT_LWPINFO extend struct ptrace_lwpinfo with additional fields used
in LLDB in the current FreeBSD process code (pl_flags, pl_child_pid,
pl_siginfo),

 - PT_GETNUMLWPS - number of kernel threads associated with the traced
process,

 - PT_GETLWPLIST - get the current thread list,

 - PT_SUSPEND - suspend the specified thread,

 - PT_RESUME - resume the specified thread.

I need to add basic tests for new ptrace(2) calls in our automated test
infrastructure in order to get this code accepted.

I will reschedule debug registers and additional ptrace(2) calls for the
end, if time will permit.

I will also add support in LLDB for handling NetBSD Real-Time signals
(SIGRTMIN..SIGRTMAX) as it was already implemented during the latest
GSoC for NetBSD (thanks Google!).

I might need some guidance from LLDB developers (I prefer via IRC and
the dedicated LLDB channel) and maybe proof reading of patches and
debugging issues. I consider that the difficult part is not adapting
FreBSD or Linux specific implementation for NetBSD, but taking
everything to work.

My ultimate deadline for the overall LLDB work is February 28th, 2017 -
as I'm switching to Swift port for NetBSD *.



This work is sponsored by The NetBSD Foundation. If you like it, please
consider supporting it by making a donation.

* http://blog.netbsd.org/tnf/entry/funded_contract_2016_2017



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] LLGS for Free/NetBSD

[Kamil Rytarowski via lldb-dev]

On 25.10.2016 01:43, Saleem Abdulrasool via lldb-dev wrote:
> On Mon, Oct 24, 2016 at 11:38 AM, Ed Maste via lldb-commits
> mailto:lldb-comm...@lists.llvm.org>> wrote:
> 
> On 24 October 2016 at 06:26, Pavel Labath  > wrote:
> >
> > It's not my place to tell you how to work, but I'd recommend a
> > different approach to this. If you base your work on the current
> > FreeBSD in-process plugin, then when you get around to actually
> > implementing remote support, you will find that you will have to
> > rewrite most of what you have already done to work with lldb-server,
> > as it uses completely different class hierarchies and everything. I'd
> > recommend starting with lldb-server right away. It's going to be a bit
> > more work as (I assume) freebsd implementation is closer to what you
> > need than linux, but I think it will save you time in the long run. I
> > can help you with factoring out any linux-specific code that you
> > encounter.
> 
> I definitely second the approach Pavel suggests here, and am happy to
> work with others on refactoring the Linux lldb-server so that we can
> get it to support both FreeBSD and NetBSD at the same time.
> 
> A direct port of the current FreeBSD support probably would result in
> a basic level of support running sooner, but that work would be
> largely thrown away in a future migration to lldb-server.
> 
> 
> Just to throw out another option: DS2 (DebugServer2) at
> http://github.com/facebook/ds2 may be another option to getting remote
> debugging working.  It already has basic BSD support, so adding NetBSD
> support shouldn't be too difficult.
>  


It's an interesting program, but for now I would leave it for later as
it's out of LLDB.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

Hello,

I've prepared two patches to make the Linux Process Plugin buildable on
NetBSD.

The diff will help to transform the Linux process plugin to common code,
shared between Linux and BSDs (FreeBSD, NetBSD).

lldb-git: Enable Linux Process plugin on NetBSD

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=commitdiff;h=4b00674e876ebfe427743759de13ead420112fd4

lldb-git: Disable unbuildable code-fragments in the
LinuxProcessPlugin/NetBSD

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=commitdiff;h=e1ef012c16ab7729918ae367150b13bf0d77650b

Comments to the disabled code:

1. Thread resume/suspend operation - to be implemented on NetBSD with
ptrace(2).

2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
add support for it in ptrace(2).

3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
equivalent to be implemented.

4. No tracing of VFORK events implemented.

5. Hardware assisted watchpoints (debug registers on amd64) have their
dedicated ptrace(2) API to set/unset watchpoints, they do not export raw
debug registers.

6. Other ptrace(2) calls have their equivalents on NetBSD
(PTRACE_PEEKUSER, PTRACE_POKEUSER etc).

7. SIGTRAP has currently only two si_code values (specified by POSIX).

8. No SI_TKILL available.

9. There is no process_vm_readv/process_vm_writev call available.

10. __WALL and __WNOTHREAD are Linux specific, but they have their
counterparts.

11. The cpu_set_t structure and appropriate functions have similar
counterparts on NetBSD.

12. No  and no dependency of procfs (/proc) is acceptable,
everything shall be accessible through ptrace(2) and sysctl(7).

13. personality.h - unsupported as header/function call, compatibility
with other OSes (mostly Linux) implemented on syscall level.

14. Process, system thread (lwp) and POSIX (pthread_t) thread are not
the same on NetBSD, unlike some other systems and cannot be mixed.


The currently missing features on the NetBSD side don't stop us from
making a functional implementation, lacing interfaces might be added
after getting the core part to work.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

On 15.12.2016 14:14, Pavel Labath wrote:
> I am communicating with Kamil about the possibility of sharing code
> between the two plugins. We plan to have a common base class for the
> shared functionality between the OSs. I have asked Kamil to perform
> this experiment, so we can identify which parts of the code can be
> shared in the first place. My thoughts on the noticed differences are
> below
> 
>>>
>>> Comments to the disabled code:
>>>
>>> 1. Thread resume/suspend operation - to be implemented on NetBSD with
>>> ptrace(2).
> This is going to be the trickiest part, as thread management works
> quite differently on the two OSs. we'll need to investigate more on
> how much we can reuse here
> 

My plan was to add two ptrace(2) calls like: PT_SUSPEND/PT_RESUME and
specify LWP to be resumed/suspended. It shouldn't be hard to implement
as there is already _lwp_suspend(2) and _lwp_continue(2), just call it
for other process with ptrace(2).

PT_CONTINUE could be kept to resume the whole process (modulo frozen
threads) along with PT_STEP. However, I was holding on with it as I
wanted to reflect it with needs of a real debugger like LLDB.

>>>
>>> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
>>> add support for it in ptrace(2).
> This value is currently only used in logging code, so we can just
> remove it from the code base. However, it's a useful thing to have for
> the future, so it may be worth making sure the NetBSD kernel supports
> it.
> 

I was wondering whether waitid(2) or wait6(2) could be used there, as
they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
entry.

>>>
>>> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
>>> equivalent to be implemented.
> Do you mean "implemented in lldb-server" or "implemented in the
> kernel"? Being notified when the inferior exec()s would definitely be
> good. Tracing thread creation and exit is a nice-to-have but low
> priority. The only reason we used it on linux is because that's the
> only way to auto-attach to new threads, but I think that for you that
> will happen automatically.
> 

I mean implemented in the kernel.

Thread (lwp) creation and termination is currently detectable in FreeBSD
with a special event, if this is useful in the NetBSD context -- like a
user setting a break on this event explicitly -- I will add it to TODO
list. On NetBSD there is no need to explicitly start tracing new
threads, tracing is per process and it is composed of a bulk of threads
(lwp). POSIX threads are a layer with extra features built upon LWP.

There is also the the exect(3) call in our libc inherited from BSD4.2,
but it no longer works in a useful way. It used to singlestep execve(2)
call. I was thinking whether/how to make it useful again, like combine
in it execve(2) + PT_TRACE_ME + SIGSTOP/SIGTRAP on exec.

>>>
>>> 4. No tracing of VFORK events implemented.
>>>
>>> 5. Hardware assisted watchpoints (debug registers on amd64) have their
>>> dedicated ptrace(2) API to set/unset watchpoints, they do not export raw
>>> debug registers.
>>>
>>> 6. Other ptrace(2) calls have their equivalents on NetBSD
>>> (PTRACE_PEEKUSER, PTRACE_POKEUSER etc).
> Cool, I guess that means we can share (Read|Write)Memory(WithoutTrap|).
> 

Functionality is the same, however the API is different.

>>>
>>> 7. SIGTRAP has currently only two si_code values (specified by POSIX).
> The code for decoding si_code values is already messy and in need of a
> rewrite. I think the act of decoding si_code values will need to be
> OS- (and maybe event architecture-) specific, but the actions taken
> upon individual events should be quite similar.
> 

I was wondering whether it is useful to return distinct si_code for
hardware assisted traps or PT_STEP. At the moment I ignored it.

>>>
>>> 8. No SI_TKILL available.
> This is used because when a single thread in a process stops, we need
> to go and manually stop all other threads. The whole function around
> this should probably be moved into the linux-specific class, as you
> don't need to do anything special to interrupt a process (IIUC).
> 

In NetBSD the whole process is stopped.

> 
>>>
>>> 9. There is no process_vm_readv/process_vm_writev call available.
> These are used only as a preformance optimization on linux. If
> (PEEK|POKE)DATA work the same way, we can put that in the base class.
> Then, linux can override and do it's fancy thing.
> 

ptrace(2) PT_IO call is our local equivalent call.

>>>
>>> 10. __WALL and __WNOTHREAD are Linux specific, but they have their
>>> counterparts.
> We should probably have a waitpid wrapper, which adds any os-specific
> flags if necessary. We can put the EINTR handling there as well to
> make it's usage easier.
> 

NetBSD ships with wait(2), wait3(2), wait4(2), wait6(2), waitid(2),
waitpid(2).

Perhaps wait4(2) or wait6(2) could be a better choice as they offer more
features, but it's an option for later.

>>>
>>> 11. The cpu_set_t structure and appro

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

On 15.12.2016 16:08, Pavel Labath wrote:
> On 15 December 2016 at 14:14, Kamil Rytarowski  wrote:
>> On 15.12.2016 14:14, Pavel Labath wrote:
>
> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
> add support for it in ptrace(2).
>>> This value is currently only used in logging code, so we can just
>>> remove it from the code base. However, it's a useful thing to have for
>>> the future, so it may be worth making sure the NetBSD kernel supports
>>> it.
>>>
>>
>> I was wondering whether waitid(2) or wait6(2) could be used there, as
>> they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
>> entry.
> 
> Note that there are two siginfo_t structures in action here. One is
> the siginfo_t the *inferior* gets as a result of some action (e.g.
> kill(), raise(), hitting an int3, etc.). The other is the siginfo_t
> corresponding to the SIGCHLD that the *debugger* gets when something
> interesting happens to the inferior. (On linux at least ), waitid(2)
> returns the second one. That one, however, generally does not contain
> any useful information apart from the process ID. PTRACE_GETSIGINFO
> returns the first one, and that one contains the interesting stuff
> (the signal the inferior recieved, and in case of a SIGTRAP, the
> information about the debug event is encoded there as well). This is
> usually very important information for the debugger.
> 
> PTRACE_SETSIGINFO allows you to overwrite the signal that the inferior
> would receive. It can be used to inject "fake" signals into the
> inferior. That can be a useful feature from time to time, but
> currently we do not support that (on linux we support injecting a
> signal via an argument to PTRACE_CONTINUE, which is a weaker
> implementation of this call, as it can only inject a signal number,
> not the full siginfo_t struct). So you may want to implement this at
> some point, but on the grand scale of things, it's not something very
> important.
> 
> 

I see, thank you for your explanation! It looks useful, but let it keep
for later.

>>
>
> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
> equivalent to be implemented.
>>> Do you mean "implemented in lldb-server" or "implemented in the
>>> kernel"? Being notified when the inferior exec()s would definitely be
>>> good. Tracing thread creation and exit is a nice-to-have but low
>>> priority. The only reason we used it on linux is because that's the
>>> only way to auto-attach to new threads, but I think that for you that
>>> will happen automatically.
>>>
>>
>> I mean implemented in the kernel.
>>
>> Thread (lwp) creation and termination is currently detectable in FreeBSD
>> with a special event, if this is useful in the NetBSD context -- like a
>> user setting a break on this event explicitly -- I will add it to TODO
>> list. On NetBSD there is no need to explicitly start tracing new
>> threads, tracing is per process and it is composed of a bulk of threads
>> (lwp). POSIX threads are a layer with extra features built upon LWP.
> BTW, are your debug registers per-process or per-thread? If they are
> per thread, then you will need to hook thread creation so you can
> inject the correct watchpoints and stuff, otherwise you will miss some
> hits. If this is handled by the kernel, then you are probably fine.
> 

Debug registers (watchpoints) are per-thread (lwp) and they are not
being inherited on thread's or process' forks. It's a valid use-case.

I just checked FreeBSD and there is PTRACE_LWP:

This event flag controls tracing of LWP kernel thread creation and
destruction. When this event is enabled, new LWPs will stop and report
an event with PL_FLAG_BORN set before executing their first instruction,
and exiting LWPs will stop and report an event with PL_FLAG_EXITED set
before completing their termination.

>>
>> There is also the the exect(3) call in our libc inherited from BSD4.2,
>> but it no longer works in a useful way. It used to singlestep execve(2)
>> call. I was thinking whether/how to make it useful again, like combine
>> in it execve(2) + PT_TRACE_ME + SIGSTOP/SIGTRAP on exec.
>>
>
> 4. No tracing of VFORK events implemented.
>
> 5. Hardware assisted watchpoints (debug registers on amd64) have their
> dedicated ptrace(2) API to set/unset watchpoints, they do not export raw
> debug registers.
>
> 6. Other ptrace(2) calls have their equivalents on NetBSD
> (PTRACE_PEEKUSER, PTRACE_POKEUSER etc).
>>> Cool, I guess that means we can share (Read|Write)Memory(WithoutTrap|).
>>>
>>
>> Functionality is the same, however the API is different.
> Ok. If the api differs by too much, then we might as well keep them as
> separate implementations. We'll see how it goes.
> 

We will see how it goes.

>>
>
> 7. SIGTRAP has currently only two si_code values (specified by POSIX).
>>> The code for decoding si_code values is already messy and in need of a
>>> rewrite. I think the act of decoding si

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

Hello,

For the reference in this thread, I've posted a blog entry on the NetBSD
Foundation site with a summary of the interfaces we were discussing in
this thread:

http://blog.netbsd.org/tnf/entry/summary_of_the_preliminary_lldb

This report covers the topics discussed in this E-mail thread.

I've got some thoughts on redefining current generic interface and
making NativeThreadX optional, but let's see what will happen when we
will get aboard appropriate support for still missing features
(registers' accessors, breakpoints, watchpoints etc).

On 15.12.2016 17:21, Kamil Rytarowski wrote:
> On 15.12.2016 16:08, Pavel Labath wrote:
>> On 15 December 2016 at 14:14, Kamil Rytarowski  wrote:
>>> On 15.12.2016 14:14, Pavel Labath wrote:
>>
>> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
>> add support for it in ptrace(2).
 This value is currently only used in logging code, so we can just
 remove it from the code base. However, it's a useful thing to have for
 the future, so it may be worth making sure the NetBSD kernel supports
 it.

>>>
>>> I was wondering whether waitid(2) or wait6(2) could be used there, as
>>> they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
>>> entry.
>>
>> Note that there are two siginfo_t structures in action here. One is
>> the siginfo_t the *inferior* gets as a result of some action (e.g.
>> kill(), raise(), hitting an int3, etc.). The other is the siginfo_t
>> corresponding to the SIGCHLD that the *debugger* gets when something
>> interesting happens to the inferior. (On linux at least ), waitid(2)
>> returns the second one. That one, however, generally does not contain
>> any useful information apart from the process ID. PTRACE_GETSIGINFO
>> returns the first one, and that one contains the interesting stuff
>> (the signal the inferior recieved, and in case of a SIGTRAP, the
>> information about the debug event is encoded there as well). This is
>> usually very important information for the debugger.
>>
>> PTRACE_SETSIGINFO allows you to overwrite the signal that the inferior
>> would receive. It can be used to inject "fake" signals into the
>> inferior. That can be a useful feature from time to time, but
>> currently we do not support that (on linux we support injecting a
>> signal via an argument to PTRACE_CONTINUE, which is a weaker
>> implementation of this call, as it can only inject a signal number,
>> not the full siginfo_t struct). So you may want to implement this at
>> some point, but on the grand scale of things, it's not something very
>> important.
>>
>>
> 
> I see, thank you for your explanation! It looks useful, but let it keep
> for later.
> 

As per-blog entry, there is now an interface for it in NetBSD with
PT_GETSIGINFO and PT_SETSIGINFO.

>>>
>>
>> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
>> equivalent to be implemented.
 Do you mean "implemented in lldb-server" or "implemented in the
 kernel"? Being notified when the inferior exec()s would definitely be
 good. Tracing thread creation and exit is a nice-to-have but low
 priority. The only reason we used it on linux is because that's the
 only way to auto-attach to new threads, but I think that for you that
 will happen automatically.

>>>
>>> I mean implemented in the kernel.
>>>
>>> Thread (lwp) creation and termination is currently detectable in FreeBSD
>>> with a special event, if this is useful in the NetBSD context -- like a
>>> user setting a break on this event explicitly -- I will add it to TODO
>>> list. On NetBSD there is no need to explicitly start tracing new
>>> threads, tracing is per process and it is composed of a bulk of threads
>>> (lwp). POSIX threads are a layer with extra features built upon LWP.
>> BTW, are your debug registers per-process or per-thread? If they are
>> per thread, then you will need to hook thread creation so you can
>> inject the correct watchpoints and stuff, otherwise you will miss some
>> hits. If this is handled by the kernel, then you are probably fine.
>>
> 
> Debug registers (watchpoints) are per-thread (lwp) and they are not
> being inherited on thread's or process' forks. It's a valid use-case.
> 
> I just checked FreeBSD and there is PTRACE_LWP:
> 
> This event flag controls tracing of LWP kernel thread creation and
> destruction. When this event is enabled, new LWPs will stop and report
> an event with PL_FLAG_BORN set before executing their first instruction,
> and exiting LWPs will stop and report an event with PL_FLAG_EXITED set
> before completing their termination.
> 
>>>
>>> There is also the the exect(3) call in our libc inherited from BSD4.2,
>>> but it no longer works in a useful way. It used to singlestep execve(2)
>>> call. I was thinking whether/how to make it useful again, like combine
>>> in it execve(2) + PT_TRACE_ME + SIGSTOP/SIGTRAP on exec.
>>>
>>
>> 4. No tracing of VFORK events implemented.

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Kamil Rytarowski via lldb-dev]

It looks fine:

diff --git a/source/Host/windows/HostInfoWindows.cpp
b/source/Host/windows/HostInfoWindows.cpp
index a965ec0ea..5b38e6021 100644
--- a/source/Host/windows/HostInfoWindows.cpp
+++ b/source/Host/windows/HostInfoWindows.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h"

 using namespace lldb_private;
@@ -90,8 +91,8 @@ bool HostInfoWindows::GetHostname(std::string &s) {
 }

 FileSpec HostInfoWindows::GetProgramFileSpec() {
-  static std::once_flag g_once_flag;
-  std::call_once(g_once_flag, []() {
+  static llvm::once_flag g_once_flag;
+  llvm::call_once(g_once_flag, []() {
 std::vector buffer(PATH_MAX);
 ::GetModuleFileNameW(NULL, buffer.data(), buffer.size());
 std::string path;

and this looks suspicious

// std::call_once from libc++ is used on all Unix platforms. Other
// implementations like libstdc++ are known to have problems on NetBSD,
// OpenBSD and PowerPC.
#if defined(LLVM_ON_UNIX) && (defined(_LIBCPP_VERSION) ||
  \
!(defined(__NetBSD__) || defined(__OpenBSD__) || defined(__ppc__)))
#define LLVM_THREADING_USE_STD_CALL_ONCE 1
#else
#define LLVM_THREADING_USE_STD_CALL_ONCE 0
#endif

This check defined(LLVM_ON_UNIX) looks wrong it assumes that Windows
needs call_once walkaround.

On 08.02.2017 22:00, Zachary Turner wrote:
> Why doesn't llvm::call_once() just use std::call_once on Windows?
> 
> On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg  > wrote:
> 
> The Win64 lldb build seems broken (at 294367).
> 
> I ran into this when trying to build the weekly snapshot
> (http://www.llvm.org/builds/) which includes LLDB these days.
> 
> I suspect this might be related to Kamil's changes a few days ago. I
> see Pavel committed something to fix Darwin afterwards.
> 
> Zach, do you know what's going on here? Do we have any buildbot
> coverage for this?
> 
>Creating library lib\liblldb.lib and object lib\liblldb.exp
> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
> external symbo
> l "void __cdecl llvm::sys::_mm_mfence(void)"
> (?_mm_mfence@sys@llvm@@YAXXZ) refer
> enced in function "void __cdecl llvm::call_once  713e15728a6adc> >(struct llvm::once_flag &,class
>  5728a6adc> &&)"
> (??$call_once@V@@$$V@ll
> 
> vm@@YAXAEAUonce_flag@0@$$QEAV@@@Z)
> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
> LINK failed. with 1120
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Kamil Rytarowski via lldb-dev]

On 08.02.2017 22:14, Kamil Rytarowski wrote:
> // std::call_once from libc++ is used on all Unix platforms. Other
> // implementations like libstdc++ are known to have problems on NetBSD,
> // OpenBSD and PowerPC.
> #if defined(LLVM_ON_UNIX) && (defined(_LIBCPP_VERSION) ||
>   \
> !(defined(__NetBSD__) || defined(__OpenBSD__) || defined(__ppc__)))
> #define LLVM_THREADING_USE_STD_CALL_ONCE 1
> #else
> #define LLVM_THREADING_USE_STD_CALL_ONCE 0
> #endif
> 
> This check defined(LLVM_ON_UNIX) looks wrong it assumes that Windows
> needs call_once walkaround.
> 

Ah not, it's OK.

If the file is windows-only it can be switched back to std:: version.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Kamil Rytarowski via lldb-dev]

On 08.02.2017 22:41, Pavel Labath wrote:
> My fix was just correcting places Kamil forgot to update (or updated
> over-excessively). It does not touch the root problem.
> 
> That said, our windows bot
>  is building
> lldb with vs2015. It does not seem to have a problem with this.
> 

Thank you for fixing it.

It was forgotten - I wanted to use consistently llvm:: namespace for
these functions across the LLDB codebase, especially since duplicated
code can be refactored to be shared and it would silently break in the
std:: version.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Shared Process plugin between Linux and BSD

[Kamil Rytarowski via lldb-dev]

I've published a short report for the previous milestone, with goals for
the ongoing one.

   "The first patch-bulk upstreamed to LLDB"

http://blog.netbsd.org/tnf/entry/the_first_patch_bulk_upstreamed

The next one will turn to be more exciting as I plan to start with
implementation of accessors for machine context registers, followed up
with breakpoints.

On 23.01.2017 15:21, Kamil Rytarowski wrote:
> Hello,
> 
> For the reference in this thread, I've posted a blog entry on the NetBSD
> Foundation site with a summary of the interfaces we were discussing in
> this thread:
> 
> http://blog.netbsd.org/tnf/entry/summary_of_the_preliminary_lldb
> 
> This report covers the topics discussed in this E-mail thread.
> 
> I've got some thoughts on redefining current generic interface and
> making NativeThreadX optional, but let's see what will happen when we
> will get aboard appropriate support for still missing features
> (registers' accessors, breakpoints, watchpoints etc).
> 
> On 15.12.2016 17:21, Kamil Rytarowski wrote:
>> On 15.12.2016 16:08, Pavel Labath wrote:
>>> On 15 December 2016 at 14:14, Kamil Rytarowski  wrote:
 On 15.12.2016 14:14, Pavel Labath wrote:
>>>
>>> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
>>> add support for it in ptrace(2).
> This value is currently only used in logging code, so we can just
> remove it from the code base. However, it's a useful thing to have for
> the future, so it may be worth making sure the NetBSD kernel supports
> it.
>

 I was wondering whether waitid(2) or wait6(2) could be used there, as
 they return siginfo_t. If so, NetBSD does not need dedicated ptrace(2)
 entry.
>>>
>>> Note that there are two siginfo_t structures in action here. One is
>>> the siginfo_t the *inferior* gets as a result of some action (e.g.
>>> kill(), raise(), hitting an int3, etc.). The other is the siginfo_t
>>> corresponding to the SIGCHLD that the *debugger* gets when something
>>> interesting happens to the inferior. (On linux at least ), waitid(2)
>>> returns the second one. That one, however, generally does not contain
>>> any useful information apart from the process ID. PTRACE_GETSIGINFO
>>> returns the first one, and that one contains the interesting stuff
>>> (the signal the inferior recieved, and in case of a SIGTRAP, the
>>> information about the debug event is encoded there as well). This is
>>> usually very important information for the debugger.
>>>
>>> PTRACE_SETSIGINFO allows you to overwrite the signal that the inferior
>>> would receive. It can be used to inject "fake" signals into the
>>> inferior. That can be a useful feature from time to time, but
>>> currently we do not support that (on linux we support injecting a
>>> signal via an argument to PTRACE_CONTINUE, which is a weaker
>>> implementation of this call, as it can only inject a signal number,
>>> not the full siginfo_t struct). So you may want to implement this at
>>> some point, but on the grand scale of things, it's not something very
>>> important.
>>>
>>>
>>
>> I see, thank you for your explanation! It looks useful, but let it keep
>> for later.
>>
> 
> As per-blog entry, there is now an interface for it in NetBSD with
> PT_GETSIGINFO and PT_SETSIGINFO.
> 

>>>
>>> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
>>> equivalent to be implemented.
> Do you mean "implemented in lldb-server" or "implemented in the
> kernel"? Being notified when the inferior exec()s would definitely be
> good. Tracing thread creation and exit is a nice-to-have but low
> priority. The only reason we used it on linux is because that's the
> only way to auto-attach to new threads, but I think that for you that
> will happen automatically.
>

 I mean implemented in the kernel.

 Thread (lwp) creation and termination is currently detectable in FreeBSD
 with a special event, if this is useful in the NetBSD context -- like a
 user setting a break on this event explicitly -- I will add it to TODO
 list. On NetBSD there is no need to explicitly start tracing new
 threads, tracing is per process and it is composed of a bulk of threads
 (lwp). POSIX threads are a layer with extra features built upon LWP.
>>> BTW, are your debug registers per-process or per-thread? If they are
>>> per thread, then you will need to hook thread creation so you can
>>> inject the correct watchpoints and stuff, otherwise you will miss some
>>> hits. If this is handled by the kernel, then you are probably fine.
>>>
>>
>> Debug registers (watchpoints) are per-thread (lwp) and they are not
>> being inherited on thread's or process' forks. It's a valid use-case.
>>
>> I just checked FreeBSD and there is PTRACE_LWP:
>>
>> This event flag controls tracing of LWP kernel thread creation and
>> destruction. When this event is enabled, new LWPs will stop and report
>> an event with PL_FLAG_BORN 

[lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

Hello,

The contract for the LLDB port on NetBSD has been prolonged by The
NetBSD Foundation. The additional time will cover the features that were
delayed in order to address blockers that were unveiled during the work
that has been done.

I've summarized the newly finished task segment in this blog entry:

http://blog.netbsd.org/tnf/entry/ptrace_2_tasks_segment_finished

My current plan is to return to LLDB and finish the following tasks:
  I. Register context and breakpoints support on NetBSD/amd64.
 II. NetBSD Threads support
III. NetBSD/i386 (32-bit x86) support.

To finalize the first goal I use LLVM/Clang/LLDB SVN rev. 296360 as the
base for my local patches. I work in pkgsrc-wip/lldb-netbsd and I
develop there local patches.

The current Test Suite status reports 267/1235 tests passed
successfully. This number of passing tests is expected to start growing
once the goals will be achieved and LLDB will be rendered into a
functional debugger on NetBSD.

===
Test Result Summary
===
Test Methods:   1235
Reruns:1
Success: 267
Expected Failure: 21
Failure: 332
Error:   167
Exceptional Exit:  0
Unexpected Success:1
Skip:444
Timeout:   3
Expected Timeout:  0

http://netbsd.org/~kamil/lldb/check-lldb-r296360-2017-02-28.txt






signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 01.03.2017 10:13, Kamil Rytarowski wrote:
> Hello,
> 
> The contract for the LLDB port on NetBSD has been prolonged by The
> NetBSD Foundation. The additional time will cover the features that were
> delayed in order to address blockers that were unveiled during the work
> that has been done.
> 
> I've summarized the newly finished task segment in this blog entry:
> 
> http://blog.netbsd.org/tnf/entry/ptrace_2_tasks_segment_finished
> 
> My current plan is to return to LLDB and finish the following tasks:
>   I. Register context and breakpoints support on NetBSD/amd64.

Halfway point status.

(LLDB developers please check the second part.)

Proper support for breakpoints is all-or-nothing, it's difficult to draw
firmly the line between "fully functional" and "implemented with bugs".
Functional software breakpoints are also the next milestone and the goal
is get tracing a simple 1-threaded program from spawning to its
termination; correctly and with all the features - as per GDB Remote
Protocol messages - in line with Linux.

Among the implemented/improved features:
 - Tracee's .text section disassembling works,
 - Backtracing (unwinding stack) of the tracee works,
 - Listing General Purpose and Special Registers works,
 - Reading General Purpose Registers works,
 - Setting software breakpoint (placing it into tracee's .text segment)
works,
 - Triggering software breakpoint (previously set with a debugger) works,
 - Rewinding Program Counter and hiding breakpoint from disassembled
.text section code works,
 - Scanning tracee's virtual address map works,
 - Reading Elf Auxiliary Vector (AUXV) works.

What clearly doesn't work is unsetting software breakpoint as the
debuggee session is crashing afterwards without proper unsetting a trap
(and the child is killed by the kernel with SIGSEGV). Software
breakpoints are all-or-nothing, enabling them keeps unveiling bugs in
code fragments which already appear to work.


TODO:
 - Fixing software breakpoints support,
 - Special Registers (Floating Point..) reading/writing,
 - Unless it will be too closely related to develop threads - Hardware
watchpoints support in line with the Linux amd64 code,


As of today the number of passing tests has been degraded. This has been
caused due the fact that LLDB endeavors to set breakpoints in every
process (on the "_start" symbol) - this blocks tracing or simulating
tracing of any process.


Not planned for this segment:
 - Fixing single step trap - it may automatically get fixed with the
above features, but it's not the goal for now. This will be part of the
threads segment.
 - Everything related to threads and x86 32-bit (i386) support.
 - Fixing other non-blocker bugs, not related to software breakpoints,
FPR, debug registers.




My plan for April+ (+ means that it might consume some of May..) is as
follows:
 - Alter the design of Resume actions to handle the whole process tasks
(next to per-thread-ones),
 - Disable emitting stop reason of all stopped threads in multithreaded
software on NetBSD as it's not applicable in our thread model (as in
contrary to Linux),
 - Alter stopped reason retrieving to ask process (NativeProcess), not
thread (NativeThread).
 - Alter watchpoints API to call the process (NativeProcess), not thread
(NativeThread).
 - Alter thread type container in process (nativeProcess) to allow to
use std::set-like containing tid (integers/lwpid_t) to store the current
image of threads.
 - Support in the current thread function "0" (or "-1" according to the
GDB Remote protocol) to mark that the whole process was interrupted/no
primary thread (from a tracer point of view)

The general goal is to eliminate NetiveThreadNetBSD, because my current
feeling is that the whole purpose of keeping this class on par with
Linux is duplicating the work already done by the NetBSD kernel. The
current result is that I need to call process-global events from
NativeThreadNetBSD and I'm enforced by the generic framework to keep
this dummy struct around. My local copy of the NativeRegisterContext
class is partly affected as well.. as ptrace(2) calls are called for the
process, not for singular threads out of the process context.

This task needs proper designing and collaboration. I think I will start
with adding basic and possible support for threads in the existing
framework and once done, move on to refactoring the generic code.

Of course any help - prior April - helping (Net)BSD threads support
landing is appreciated!

>  II. NetBSD Threads support
> III. NetBSD/i386 (32-bit x86) support.
> 
> To finalize the first goal I use LLVM/Clang/LLDB SVN rev. 296360 as the
> base for my local patches. I work in pkgsrc-wip/lldb-netbsd and I
> develop there local patches.
> 
> The current Test Suite status reports 267/1235 tests passed
> successfully. This number of passing tests is expected to start growing
> once the goals will be achieved and LLDB will be rendered into a
> functional debugger on NetBSD.
> 
> ===
> Te

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 16.03.2017 11:55, Pavel Labath wrote:
> On 16 March 2017 at 00:43, Kamil Rytarowski  wrote:
>>
>> TODO:
>>  - Fixing software breakpoints support,

Fixed!

267->596 of succeeded tests out of 1200+ - please scroll for details.

>>  - Special Registers (Floating Point..) reading/writing,
>>  - Unless it will be too closely related to develop threads - Hardware
>> watchpoints support in line with the Linux amd64 code,
>>
>>
>> As of today the number of passing tests has been degraded. This has been
>> caused due the fact that LLDB endeavors to set breakpoints in every
>> process (on the "_start" symbol) - this blocks tracing or simulating
>> tracing of any process.
> This is necessary so that we can read the list shared libraries loaded
> by the process and set any breakpoints in them. Note that currently
> (at least on Linux) we are doing it actually too late -- at this point
> the constructors in the shared libraries have already executed, so we
> cannot set breakpoints or debug the initialization code. I haven't yet
> investigated how to fix this.
> 

I see.

It's interesting use-case; Right now I'm not sure how properly address it.

Thank you for your insight.

> We will need to discuss this in detail. I am not sure removing the
> NativeThreadNetBSD class completely will is a worthwhile goal, but we
> can certainly work towards making it's parent class dumber, and remove
> operations that don't make sense for all users. If e.g. your
> watchpoints are per-process, then we can pipe watchpoint setting code
> through NativeProcessProtocol, and NativeProcessNetBSD will implement
> that directly, while the linux version will delegate to the thread.
> However, even in your process model each thread has a separate set of
> registers, so I think it makes sense to keep the register manipulation
> code there.
> 

I put all the threading potential challenges, each one will need to be
discussed. Refactoring is by definition cost and should be reduced to
minimum, while getting proper support on the platform. I think

Our watchpoints (debug registers) are per-thread (LWP) only.

>>  - Support in the current thread function "0" (or "-1" according to the
>> GDB Remote protocol) to mark that the whole process was interrupted/no
>> primary thread (from a tracer point of view)
> Teaching all parts of the debugger (server is not enough, I think you
> would have to make a lot of client changes as well) about
> whole-process events might be a big task.

I think long term this might be useful. I noted in the GDB Remote
specification that this protocol is embeddable into simulators and
low-level kernel APIs without regular threads, however it's not urgently
needed to get aboard for standard user-level debugging facilities; while
it will be useful in the general set of capabilities in future.

> I wondering whether you
> wouldn't make more progress if you just fudged this and always
> attributed these events to the primary thread. I think we would be in
> a better position to design this properly once most of the debugger
> functionality was operational for you.

Agreed.

This is why the initial goal of mine is to get as far as possible
without touching the generic subsystems and get basic threading support.

> What kind of per-process events
> are we talking about here?

I'm mostly thinking about ResumeActions - to resume the whole process,
while being able single-stepping desired thread(s).

(We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).

> Is there anything more here than a signal
> directed at the whole process?

single-stepping
resume thread
suspend thread

I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
marks a thread for single-stepping. This code is needed to allow us to
combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.

I was thinking about ResumeActions marking which thread to
resume/suspend/singlestep, whether to emit a signal (one per global
PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.

To some certain point it might be kludged with single-thread model for
basic debugging.


I imagined a possible flow of ResumeAction calls like:
[Generic/Native framework knows upfront the image of threads within
debuggee]
 - Resume Thread 2 (PT_RESUME)
 - Suspend Thread 3 (PT_SUSPEND)
 - Set single-step Thread 2 (PT_SETSTEP)
 - Set single-step Thread 4 (PT_SETSTEP)
 - Clear single-step Thread 5 (PT_CLEARSTEP)
 - Resume & emit signal SIGIO (PT_CONTINUE)

In other words: setting properties on threads and pushing the
PT_CONTINUE button at the end.

> AFAICT, most of the stop reasons
> (breakpoint, watchpoint, single step, ...) are still linked to a
> specific thread even in your process model. I think you could get to a
> point where lldb is very useful even without getting these events
> "correct".
> 

I was thinking for example about this change (it's not following the
real function name nor the prototype):

  GetStoppedReason(Thread) -> GetStoppedReason(Pr

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 16.03.2017 22:59, Jim Ingham wrote:
> But it looks like all the "whole process" events you are talking about are 
> not stop reasons but more start actions.  That makes sense, but what whole 
> process stop events do you mean?

A process can be stopped with a signal. A signal can be emitted to:
(1) a particular thread,
(2) the whole process.

A particular thread can be stopped due to:
 - [PL_EVENT_SIGNAL] being signaled (a signal emitted to the whole
process or this particular thread)
 - [PL_EVENT_SUSPENDED] being suspended (PT_SUSPEND, _lwp_suspend(2) or
similar),
 - [PL_EVENT_NONE] no action the whole process stopped, because of a
sibling thread that was signaled

If there was no particular thread targeted with a signal we cannot
retrieve the thread that caused interruption of the process. It differs
to FreeBSD and Linux as these systems offer always a thread that is
culprit for interruption. In this scenario we would use "currentthread =
whole process".

The GDB Remote Protocol handles it with special thread numbers 0 and -1.
(I'm not certain what's the exact difference between "all threads" and
"any thread" in the protocol).

In my local code, I'm populating all threads within the tracee
(NativeThread) with exactly the same stop reason - for the "whole
process" case. I can see - on the client side - that it prints out the
same message for each thread within the process as all of them captured
a stop action.

In Linux, it is possible to trigger multiple stop reasons on each thread
separately, on NetBSD the first one wins. LLDB offers an extension in
the GDB Remote Protocol to transfer stop reasons from all threads that
were stopped due to some occurred event. This is not applicable on
NetBSD. Faking it, this or that way, can be good enough for the first
initial and functional port, but there is in my opinion technical dept
over the port.

This can be kludged and I can set as the current thread (the one that
caused interruption) the previously used one or the first one in the list.

I'm evaluating it from the point of view of a tracee with 10.000 threads
and getting efficient debugging experience. This is why I would ideally
reduce NativeThread to a container that is sorted, hashale box of
integers (lwpid_t) and shut down stopped reason extension called for
each stopped in debuggee.

But first things first, I need to make it functional with dummy
solutions first.

And yes, I actually want to be able to debug 10.000 LWPs within a debugger.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 17.03.2017 01:37, Jim Ingham wrote:
> The main consumer of thread stop reasons is the execution control 
> (ThreadPlans - which handle stepping & function calling - and 
> StopInfo::PerformAction which handles breakpoint/watchpoint hits).  The only 
> bad effect of populating all the threads with the whole process signals is if 
> any of the plans did anything special with that signal.  Some of the thread 
> plans do care about a few signals, but those are mostly SIGSEGV and the like 
> (the function calling plans care about this.)  I can't see what it would mean 
> to send a whole process SIGSEGV, however, that seems like it is always going 
> to be a thread specific thing.  Ditto for however you see a breakpoint hit 
> (SIGTRAP?)  Those really have to be thread specific...
> 
> I can't think of anything else this would really affect, so going forward 
> with your "process => all threads" fiction is probably fine for a first pass.
> 
> Jim
> 

Thank you for your analysis.

I can check siginfo(2) of each signal and verify it. ptrace(2)
(PT_GET_SIGINFO) gives me destination of a signal:
specific-thread/all-threads. The siginfo(2) structures gives signal's
source/reason. For example si_code can contain SI_USER for kill(2),
SI_QUEUE for sigqueue(2) etc.

Hypothetically someone would pass SIGSEGV manually for the whole process
- eg. using the kill(1) command - but it's rather anomaly and I don't
expect a debugger to have a defined behavior for such events. I would
just pass that sort of signals to the child and ignore in the
MonitorCallback code.

The NetBSD version of raise(3) uses _lwp_kill(2) a LWP-specific kill(2)
to emit a signal to a specified thread within the same process. Just for
sake of curiosity - the FreeBSD LLDB code breaks (assert(3) fires) after
calling "raise(SIGTRAP)" from the child.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD extended set of tasks

[Kamil Rytarowski via lldb-dev]

On 17.03.2017 10:48, Pavel Labath wrote:
> On 16 March 2017 at 21:43, Kamil Rytarowski >
>> I imagined a possible flow of ResumeAction calls like:
>> [Generic/Native framework knows upfront the image of threads within
>> debuggee]
>>  - Resume Thread 2 (PT_RESUME)
>>  - Suspend Thread 3 (PT_SUSPEND)
>>  - Set single-step Thread 2 (PT_SETSTEP)
>>  - Set single-step Thread 4 (PT_SETSTEP)
>>  - Clear single-step Thread 5 (PT_CLEARSTEP)
>>  - Resume & emit signal SIGIO (PT_CONTINUE)
>>
>> In other words: setting properties on threads and pushing the
>> PT> > wrote:
>> On 16.03.2017 11:55, Pavel Labath wrote:
>>> What kind of per-process events
>>> are we talking about here?
>>
>> I'm mostly thinking about ResumeActions - to resume the whole process,
>> while being able single-stepping desired thread(s).
>>
>> (We also offer PT_SYSCALL feature, but it's not needed right now in LLDB).
>>
>>> Is there anything more here than a signal
>>> directed at the whole process?
>>
>> single-stepping
>> resume thread
>> suspend thread
>>
>> I'm evaluating FreeBSD-like API PT_SETSTEP/PT_CLEARSTEP for NetBSD. It
>> marks a thread for single-stepping. This code is needed to allow us to
>> combine PT_SYSCALL & PT_STEP and PT_STEP & emit signal.
>>
>> I was thinking about ResumeActions marking which thread to
>> resume/suspend/singlestep, whether to emit a signal (one per global
>> PT_CONTINUE[/PT_SYSCALL]) and whether to resume the whole thread.
>>
>> To some certain point it might be kludged with single-thread model for
>> basic debugging.
>>_CONTINUE button at the end.
> 
> None of this is really NetBSD-specific, except the whole-process signal
> at the end (which I am going to ignore for now). I mean, the
> implementation of it is different, but there is no reason why someone
> would not want to perform the same set of actions on Linux for instance.
> I think most of the work here should be done on the client. Then, when
> the user issues the final "continue", the client sends something like
> $vCont;s:2;s:4;c:5. Then it's up to the server to figure out how execute
> these actions. On NetBSD it would execute the operations you mention
> above, while on linux it would do something like
> ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4);
> ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this
> actually, although you may have a hard time convincing the client to
> send a packet like that).
> 

Right. I also don't expect the LLDB client to export so fine-grained
commands for a user. I don't think that it would be appropriate in C-API
either. Something similar to "set scheduler-lock on" from GDB, with
single-step option sounds fine for my purposes.

I was thinking about a division between setting thread plan and resuming
the execution. We will be back to it once I will be working on threads.

> So I don't believe there will be any sweeping changes necessary to
> support this in the future. If I understand it correctly, you are
> working on the server now. All you need to do there is to make sure you
> translate the set of actions in the packet to the proper sequence of
> ptrace calls. You can even write lldb-server-style tests for that. Then,
> we can discuss what would be the best user-level interface to specify
> complex actions like this, and teach the client to send these packets.
> 

I see, makes sense.

>>
>>> AFAICT, most of the stop reasons
>>> (breakpoint, watchpoint, single step, ...) are still linked to a
>>> specific thread even in your process model. I think you could get to a
>>> point where lldb is very useful even without getting these events
>>> "correct".
>>>
>>
>> I was thinking for example about this change (it's not following the
>> real function name nor the prototype):
>>
>>   GetStoppedReason(Thread) -> GetStoppedReason(Process,Thread)
>>
>> The Linux code would easily route it to desired thread and (Net)BSD
>> return immediately the requested data. The need to have these functions
>> in NativeThread (enforced by the framework) is the only purpose I keep
>> them there, while there is global stopped reason on NetBSD (per-process).
> 
> Ok, I think we can talk about tweaks like that once you have something
> upstream. Right now it does not seem to me like that should pose a big
> development obstacle.
> 

It might be similar with hardware assisted watchpoints, but let's
discuss it later.

> 
> In my local code, I'm populating all threads within the tracee
> (NativeThread) with exactly the same stop reason - for the "whole
> process" case. I can see - on the client side - that it prints out the
> same message for each thread within the process as all of them captured
> a stop action.
> 
> 
> Indeed, that can be a nuissance. The whole-process events is probably
> the first thing we should look at after the port is operational. I think
> this can be handled independently of the fancy resume actions we talk
> about above, which as Jim pointed out

[lldb-dev] Aprilis LLDB/NetBSD

[Kamil Rytarowski via lldb-dev]

Hello,

I've dropped few paragraphs on the NetBSD status:

https://blog.netbsd.org/tnf/entry/netbsd_the_first_bsd_introducing

I'm going to focus on the following tasks till Easter holidays
 * watchpoints support,
 * floating point registers support,
 * enhance core(5) and make it work for multiple threads
 * introduce PT_SETSTEP and PT_CLEARSTEP in ptrace(2)
 * research F_GETPATH in fcntl(2)

On the second half of this month I will move on to:
 * support threads in the NetBSD Process Plugin


Upstream LLVM+Clang+LLDB version r. 299109 (no local patches) verification*:

===
Test Result Summary
===
Test Methods:   1247
Reruns:0
Success: 622
Expected Failure: 23
Failure:  79
Error:97
Exceptional Exit:  0
Unexpected Success:1
Skip:424
Timeout:   1
Expected Timeout:  0

http://netbsd.org/~kamil/lldb/check-lldb-r299109-2017-04-04.txt

* I'm still using pkgsrc-wip and it might affect the score compared to
clean out of pkgsrc build.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Aprilis LLDB/NetBSD

[Kamil Rytarowski via lldb-dev]

On 05.04.2017 00:52, Christos Zoulas wrote:
> On Apr 4, 10:24pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Aprilis LLDB/NetBSD
> 
> | Hello,
> | 
> | I've dropped few paragraphs on the NetBSD status:
> | 
> | https://blog.netbsd.org/tnf/entry/netbsd_the_first_bsd_introducing
> | 
> | I'm going to focus on the following tasks till Easter holidays
> |  * watchpoints support,
> |  * floating point registers support,
> |  * enhance core(5) and make it work for multiple threads
> |  * introduce PT_SETSTEP and PT_CLEARSTEP in ptrace(2)
> |  * research F_GETPATH in fcntl(2)
> | 
> | On the second half of this month I will move on to:
> |  * support threads in the NetBSD Process Plugin
> | 
> | 
> | Upstream LLVM+Clang+LLDB version r. 299109 (no local patches) verification*=
> | :
> | 
> | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> | Test Result Summary
> | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> | Test Methods:   1247
> | Reruns:0
> | Success: 622
> | Expected Failure: 23
> | Failure:  79
> | Error:97
> | Exceptional Exit:  0
> | Unexpected Success:1
> | Skip:424
> | Timeout:   1
> | Expected Timeout:  0
> | 
> | http://netbsd.org/~kamil/lldb/check-lldb-r299109-2017-04-04.txt
> | 
> | * I'm still using pkgsrc-wip and it might affect the score compared to
> | clean out of pkgsrc build.
> 
> What enhancements do we need for the core format?

Currently there is nothing planned on the base system side. All the
enhancements are to be done on the LLDB side.

Our core-dump files contain notes like: "NetBSD-CORE@1". This "1" is LWP
and it must be properly handled in LLDB to define a thread. Currently
LLDB just recognizes NetBSD-CORE files and "NetBSD-CORE" notes. It needs
now to instantiate appropriate threads.

On the other hand I've studied inspiring articles like:
"FreeBSD Userspace Coredumps"
https://backtrace.io/blog/blog/2015/10/03/whats-a-coredump/index.html

Presenting a list of improvements for the NetBSD system is currently
premature for me as I need to study up more on the topic. It appears
also beyond the tasks related to LLDB.

In other words we seem to be good enough to get all the needed things done.

> Sounds good, do you have the PT_{G,S}ETSTEP functional description somewhere?
> 

PT_SETSTEP This request will turn on single stepping of the specified
process.

PT_CLEARSTEP This request will turn off single stepping of the specified
process.

In NetBSD case:
 ptrace(PT_SETSTEP, pid, NULL, lwp);
 ptrace(PT_CLEARSTEP, pid, NULL, lwp);

I'm going to cleanup it and send for review.

> christos
> 





signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Aprilis LLDB/NetBSD

[Kamil Rytarowski via lldb-dev]

On 05.04.2017 02:21, Christos Zoulas wrote:
> On Apr 5,  1:10am, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: Aprilis LLDB/NetBSD
> 
> | Currently there is nothing planned on the base system side. All the
> | enhancements are to be done on the LLDB side.
> | 
> | Our core-dump files contain notes like: "NetBSD-CORE@1". This "1" is LWP
> | and it must be properly handled in LLDB to define a thread. Currently
> | LLDB just recognizes NetBSD-CORE files and "NetBSD-CORE" notes. It needs
> | now to instantiate appropriate threads.
> | 
> | On the other hand I've studied inspiring articles like:
> | "FreeBSD Userspace Coredumps"
> | https://backtrace.io/blog/blog/2015/10/03/whats-a-coredump/index.html
> | 
> | Presenting a list of improvements for the NetBSD system is currently
> | premature for me as I need to study up more on the topic. It appears
> | also beyond the tasks related to LLDB.
> | 
> | In other words we seem to be good enough to get all the needed things done.=
> 
> Ok, so nothing so far to do.
> 

Well, we might want to build some interfaces like one to pass
siginfo_t.. however I don't think this is that important for core(5)
files as of now to get them just functional. There is already
infrastructure in the kernel for this (as far as I remember we pass it
in p_sigctx) that could be reused in future.

There is certainly room for improvement, but nothing stops us.

> | > Sounds good, do you have the PT_{G,S}ETSTEP functional description somewh=
> | ere?
> | >=20
> | 
> | PT_SETSTEP This request will turn on single stepping of the specified
> | process.
> | 
> | PT_CLEARSTEP This request will turn off single stepping of the specified
> | process.
> | 
> | In NetBSD case:
> |  ptrace(PT_SETSTEP, pid, NULL, lwp);
> |  ptrace(PT_CLEARSTEP, pid, NULL, lwp);
> | 
> | I'm going to cleanup it and send for review.
> 
> Yes, but as PT_STEP is things going to be an MD thing? How will it be
> implemented?
> 

Yes, I planned to add it as MD.

In the source code protect it with
#ifdef PT_STEP
PT_STEP:
PT_SETSTEP:
PT_CLEARSTEP:
#endif

I will show a patch tomorrow.

> christos
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Improve performance of crc32 calculation

[Kamil Rytarowski via lldb-dev]

There is a good crc32c (assuming we want crc32c) code in DPDK
(BSD-licensed).

http://dpdk.org/browse/dpdk/tree/lib/librte_hash

It has hardware assisted algorithm for x86 and arm64 (if hardware
supports it). There is a fallback to lookup table implementation.

CRC32 is definitely worth merging with LLVM.

On 13.04.2017 13:28, Pavel Labath via lldb-dev wrote:
> Improving the checksumming speed is definitely a worthwhile
> contribution, but be aware that there is a pretty simple way to avoid
> computing the crc altogether, and that is to make sure your binaries
> have a build ID. This is generally as simple as adding -Wl,--build-id to
> your compiler flags.
> 
> +1 to moving the checksumming code to llvm
> 
> pl
> 
> On 13 April 2017 at 07:20, Zachary Turner via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> I know this is outside of your initial goal, but it would be really
> great if JamCRC be updated in llvm to be parallel. I see that you're
> making use of TaskRunner for the parallelism, but that looks pretty
> generic, so perhaps that could be raised into llvm as well if it helps.
> 
> Not trying to throw extra work on you, but it seems like a really
> good general purpose improvement and it would be a shame if only
> lldb can benefit from it.
> On Wed, Apr 12, 2017 at 8:35 PM Scott Smith via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Ok I stripped out the zlib crc algorithm and just left the
> parallelism + calls to zlib's crc32_combine, but only if we are
> actually linking with zlib.  I left those calls here (rather
> than folding them info JamCRC) because I'm taking advantage of
> TaskRunner to parallelize the work.
> 
> I moved the system include block after the llvm includes, both
> because I had to (to use the config #defines), and because it
> fit the published coding convention.
> 
> By itself, it reduces my test time from 55 to 47 seconds. (The
> original time is slower than before because I pulled the latest
> code, guess there's another slowdown to fix).
> 
> On Wed, Apr 12, 2017 at 12:15 PM, Scott Smith
>  > wrote:
> 
> The algorithm included in ObjectFileELF.cpp performs a byte
> at a time computation, which causes long pipeline stalls in
> modern processors.  Unfortunately, the polynomial used is
> not the same one used by the SSE 4.2 instruction set, but
> there are two ways to make it faster:
> 
> 1. Work on multiple bytes at a time, using multiple lookup
> tables. (see
> http://create.stephan-brumme.com/crc32/#slicing-by-8-overview 
> )
> 2. Compute crcs over separate regions in parallel, then
> combine the results.  (see
> 
> http://stackoverflow.com/questions/23122312/crc-calculation-of-a-mostly-static-data-stream
> 
> )
> 
> As it happens, zlib provides functions for both:
> 1. The zlib crc32 function uses the same polynomial as
> ObjectFileELF.cpp, and uses slicing-by-4 along with loop
> unrolling.
> 2. The zlib library provides crc32_combine.
> 
> I decided to just call out to the zlib library, since I see
> my version of lldb already links with zlib; however, the
> llvm CMakeLists.txt declares it optional.
> 
> I'm including my patch that assumes zlib is always linked
> in.  Let me know if you prefer:
> 1. I make the change conditional on having zlib (i.e. fall
> back to the old code if zlib is not present)
> 2. I copy all the code from zlib and put it in
> ObjectFileELF.cpp.  However, I'm going to guess that
> requires updating some documentation to include zlib's
> copyright notice.
> 
> This brings startup time on my machine / my binary from 50
> seconds down to 32.
> (time ~/llvm/build/bin/lldb -b -o 'b main' -o 'run' MY_PROGRAM)
> 
> 
> ___
> 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] Aprilis LLDB/NetBSD

[Kamil Rytarowski via lldb-dev]

On 04.04.2017 22:24, Kamil Rytarowski wrote:
> Hello,
> 

Hello,

Short update.

> I've dropped few paragraphs on the NetBSD status:
> 
> https://blog.netbsd.org/tnf/entry/netbsd_the_first_bsd_introducing
> 
> I'm going to focus on the following tasks till Easter holidays

On time.

>  * watchpoints support,

Functional and pending upstream:
https://reviews.llvm.org/D32080

There is a bug with watchpoints that they are reported like PT_STEP.. I
don't know what's going on, I moved on to other tasks for now as this
does not stop other features and the general functionality of
watchpoints, even if they are incorrectly reported.

>  * floating point registers support,

Functional and pending upstream:
https://reviews.llvm.org/D32080

We need to add XSAVE ans XSAVEOPT into ptrace(2) and apparently into
mcontext. As of now AVX and similar registers are hidden from the
mentioned interfaces.

>  * enhance core(5) and make it work for multiple threads

Functional and pending upstream:
https://reviews.llvm.org/D32149

In general the original code was buggy and I decided to go for a custon
NetBSD-specific function to decode thread context notes. As doing it in
the same loop function with Linux would produce monstrous code.

>  * introduce PT_SETSTEP and PT_CLEARSTEP in ptrace(2)

Committed into the kernel.

>  * research F_GETPATH in fcntl(2)

Currently we decided to not introduce this. The general feeling of the
core developers is to handle this functionality on the LLDB side (in
case it will be needed on NetBSD).

The Linux specific fallback (reading /proc) is not acceptable.

> 
> On the second half of this month I will move on to:
>  * support threads in the NetBSD Process Plugin
> 

High time to switch to this task now.

> 
> Upstream LLVM+Clang+LLDB version r. 299109 (no local patches) verification*:
> 
> ===
> Test Result Summary
> ===
> Test Methods:   1247
> Reruns:0
> Success: 622
> Expected Failure: 23
> Failure:  79
> Error:97
> Exceptional Exit:  0
> Unexpected Success:1
> Skip:424
> Timeout:   1
> Expected Timeout:  0
> 
> http://netbsd.org/~kamil/lldb/check-lldb-r299109-2017-04-04.txt
> 
> * I'm still using pkgsrc-wip and it might affect the score compared to
> clean out of pkgsrc build.
> 

There is a minimal increment of successfully passed tests. Partly due to
the stop status reported for watchpoints.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch to Attach pid successfully from different dir

[Kamil Rytarowski via lldb-dev]

On 19.04.2017 16:15, vignesh balu via lldb-dev wrote:
> Hi,
> Firstly, I am new to the community, So please bear with my mistakes and
> guide me to be on your wavelength.
> 
> While using lldb we found the small bug with attaching to the running
> process. 
> "attach" works fine when we run the lldb on the same dir where we ran
> the executable but not if the dir changes.
> 
>> cd lldb_temp/
>> ./test &
> [2] 39044
>> cd ../
>> /b/vignesh/lldb_daily_build/20170419_bkup/binaries/bin/lldb
> (lldb) attach 39044
> error: attach failed: unable to find executable for './test'
> 
> I see the lldb using the relative path instead of absolute path of the exe.
> Modified the way sysctl gets the exe name to get the absolute path.
> 
> Attached the patch which does the work. I did my testing on Fbsd10.
> Please let me know how to commit it
> 
> -regards,
> vbalu
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

Please submit your code to https://reviews.llvm.org/

Please try to use clang-format before submission.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch to Attach pid successfully from different dir

[Kamil Rytarowski via lldb-dev]

Thanks, Ed Maste is the current FreeBSD maintainer.

On 20.04.2017 07:36, vignesh balu wrote:
> Created Review : https://reviews.llvm.org/D32271 
> 
> Do i need to assign the reviewers ? if so please let me know how to get
> reviewers list.
> 
> -vbalu
> 
> 
> On Wed, Apr 19, 2017 at 7:59 PM, Kamil Rytarowski  > wrote:
> 
> On 19.04.2017 16:15, vignesh balu via lldb-dev wrote:
> > Hi,
> > Firstly, I am new to the community, So please bear with my
> mistakes and
> > guide me to be on your wavelength.
> >
> > While using lldb we found the small bug with attaching to the running
> > process.
> > "attach" works fine when we run the lldb on the same dir where we ran
> > the executable but not if the dir changes.
> >
> >> cd lldb_temp/
> >> ./test &
> > [2] 39044
> >> cd ../
> >> /b/vignesh/lldb_daily_build/20170419_bkup/binaries/bin/lldb
> > (lldb) attach 39044
> > error: attach failed: unable to find executable for './test'
> >
> > I see the lldb using the relative path instead of absolute path of
> the exe.
> > Modified the way sysctl gets the exe name to get the absolute path.
> >
> > Attached the patch which does the work. I did my testing on Fbsd10.
> > Please let me know how to commit it
> >
> > -regards,
> > vbalu
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> >
> 
> Please submit your code to https://reviews.llvm.org/
> 
> Please try to use clang-format before submission.
> 
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] NetBSD core(5) files for LLDB's test-suite

[Kamil Rytarowski via lldb-dev]

Hello,

I've prepared two sets of core(5) files with the following programs:
 - 1lwp_SIGSEGV (signal SIGSEGV emitted for thread)
 - 1lwp_busyloop (signal SIGABRT emitted for the whole process)

My compiler is GCC 5.4.0 and host NetBSD/amd64 7.99.70.

The first set is written with a custom startup assembly without usage of
libc. I used -nostdlib option for the compiler. The second set is plain
C implementation.

The first set generates files of size 6752 bytes/core. After compressing
with the default options of bzip2, the size is respectively 1035 and 990
bytes.

The second set in C with regular system libraries gives core(5) files of
size 103488 and 103472 bytes. bzip2 with the default options reduces
their size to 15212 and 15040 bytes.


Writing bare code starting additional LWP in the first approach is more
difficult, especially since it will need to be ported to more platforms.
I decided to implement just the libc version and go for native lwp
interfaces and without usage of libpthread.

The size of core(5) files is as follows: 131800 and 131784 bytes.
Compressed with the default options of bzip2: 16345 and 16243 bytes.


I propose to go for regular libc code version and optionally compress
the binary files. I request to include Makefile and source code of files
to LLDB. I propose to ship 4 core files per supported target architecture.


I put the source code and NetBSD/amd64 core(5) files ready to pick-up here:
http://www.netbsd.org/~kamil/lldb/netbsd-core/


For the reference, I include the used source code below:

Source C code:
$ cat 1lwp_SIGSEGV.c
void main(void)
{
volatile int *a = 0;
*a = 100;
}
$ cat 1lwp_busyloop.c
int main(int argc, char **argv)
{
for(;;)
continue;
}


Startup assembly (there is replaced @VERSION@ with __NetBSD_Version__
from /usr/include/sys/param.h):
.globl _start

.section ".note.netbsd.ident", "a", @note
.long 2f-1f
.long 4f-3f
.long 1
1:  .asciz "NetBSD"
2:  .p2align 2
3:  .long @VERSION@
4:  .p2align 2

.section .text
_start:
andq $0xfff0, %rsp
subq $0x8, %rsp
call main



Source code with two LWPs (without libpthread):
#include 
#include 
#include 

static void
lwp_main_func(void *arg)
{
#if 1
volatile int *a = 0;
*a = 100;
#else
for(;;)
continue;
#endif
}

int
main(int argc, char **argv)
{
ucontext_t uc;
lwpid_t lid;
static const size_t ssize = 16*1024;
void *stack;

stack = malloc(ssize);
_lwp_makecontext(&uc, lwp_main_func, NULL, NULL, stack, ssize);
_lwp_create(&uc, 0, &lid);
_lwp_wait(lid, NULL);   
}



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

[Kamil Rytarowski via lldb-dev]

Hello,

I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.

It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with
the GNU toolchain.

Once the new one setup will be in operation, I will upgrade the old one
to 7.99.70 (& retain the same name), switch the to the staging cluster
http://lab.llvm.org:8014/ and turn on execution of tests.

Am I right that in order to turn tests I need to switch "runTest=False"
to "runTest=True" in buildbot/osuosl/master/config/builders.py?

Once the setup for tests will stabilize I will turn them on in
lldb-amd64-ninja-netbsd8 in the main cluster.


The new build node is hosted by The NetBSD Foundation.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

[Kamil Rytarowski via lldb-dev]

On 24.04.2017 11:42, Pavel Labath wrote:
> 
> 
> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Hello,
> 
> I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.
> 
> It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with
> the GNU toolchain.
> 
> Once the new one setup will be in operation, I will upgrade the old one
> to 7.99.70 (& retain the same name), switch the to the staging cluster
> http://lab.llvm.org:8014/ and turn on execution of tests.
> 
> Am I right that in order to turn tests I need to switch "runTest=False"
> to "runTest=True" in buildbot/osuosl/master/config/builders.py?
> 
> 
> Affirmative.
> 
> As you are using the "scripted" build factory, you'll also need to
> create a  test_cfg.json in your scripts folder on the build slave, which
> describes the kind of tests you want to run:
> For example, the linux build bot has this in the file:
> {
> "test1": "local,clang-3.5,i386",
> "test2": "local,clang-3.5,x86_64",
> "test3": "local,totclang,i386",
> "test4": "local,totclang,x86_64",
> "test5": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,i386",
> "test6": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,x86_64"
> }
> but a single test line would probably be enough for you.
> Then, the master will invoke a script "test.sh" with the test config
> argument: (e.g., ./test.sh local,clang-3.5,i386) and your script should
> run the tests.
> 
> let me know if you run into problems,
> pl

Thank you, I will give it a try and let you know about the status.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

[Kamil Rytarowski via lldb-dev]

On 24.04.2017 11:42, Pavel Labath wrote:
> 
> 
> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Hello,
> 
> I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.
> 
> It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with
> the GNU toolchain.
> 
> Once the new one setup will be in operation, I will upgrade the old one
> to 7.99.70 (& retain the same name), switch the to the staging cluster
> http://lab.llvm.org:8014/ and turn on execution of tests.
> 
> Am I right that in order to turn tests I need to switch "runTest=False"
> to "runTest=True" in buildbot/osuosl/master/config/builders.py?
> 
> 
> Affirmative.
> 
> As you are using the "scripted" build factory, you'll also need to
> create a  test_cfg.json in your scripts folder on the build slave, which
> describes the kind of tests you want to run:
> For example, the linux build bot has this in the file:
> {
> "test1": "local,clang-3.5,i386",
> "test2": "local,clang-3.5,x86_64",
> "test3": "local,totclang,i386",
> "test4": "local,totclang,x86_64",
> "test5": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,i386",
> "test6": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,x86_64"
> }
> but a single test line would probably be enough for you.
> Then, the master will invoke a script "test.sh" with the test config
> argument: (e.g., ./test.sh local,clang-3.5,i386) and your script should
> run the tests.
> 
> let me know if you run into problems,
> pl

lldb-amd64-ninja-netbsd8 [kernel ABI version 7.99.70] is up and running

lldb-amd64-ninja-netbsd7 has been upgraded to 7.99.70 and restarted

I switched the old machine to the staging buildfarm, set runTest=True in
buildbot/osuosl/master/config/builders.py and added the following
test_cfg.json:

$ cat ./build/build/test_cfg.json
{
"test1": "local,gcc,x86_64",
}

As of now it does not attempt to run the regression tests. Perhaps we
need to restart buildmaster configuration? I will ask Galina for it.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

[Kamil Rytarowski via lldb-dev]

I've managed to configure lldb-amd64-ninja-netbsd7 to run the unit
tests. There has been observed a regression as the number of passing
ones dropped recently from 600+/1200+ to 200+. I've reproduced this also
locally.

http://lab.llvm.org:8014/builders/lldb-amd64-ninja-netbsd7/builds/75

I'm still using google scripts. I think we should drop "upload test
traces" on !Google platforms.

Long term I'm planning to prepare my own set of scripts customized for
NetBSD. I'm evaluation inclusion LLVM and Clang tests in execution to
maximize usage of the new buildbot. Perhaps I will be able to spare my
time on it around September.

For now I will try to mark failing ones with expected failure and file
Bugzilla bugs for them. I'm going to turn on tests on
lldb-amd64-ninja-netbsd8.

On 28.04.2017 13:15, Pavel Labath wrote:
> Indeed,  master restart is needed every time you update the zorg repository.
> 
> cheers,
> pl
> 
> On 28 April 2017 at 03:40, Kamil Rytarowski  wrote:
>> On 24.04.2017 11:42, Pavel Labath wrote:
>>>
>>>
>>> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>
>>> Hello,
>>>
>>> I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.
>>>
>>> It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with
>>> the GNU toolchain.
>>>
>>> Once the new one setup will be in operation, I will upgrade the old one
>>> to 7.99.70 (& retain the same name), switch the to the staging cluster
>>> http://lab.llvm.org:8014/ and turn on execution of tests.
>>>
>>> Am I right that in order to turn tests I need to switch "runTest=False"
>>> to "runTest=True" in buildbot/osuosl/master/config/builders.py?
>>>
>>>
>>> Affirmative.
>>>
>>> As you are using the "scripted" build factory, you'll also need to
>>> create a  test_cfg.json in your scripts folder on the build slave, which
>>> describes the kind of tests you want to run:
>>> For example, the linux build bot has this in the file:
>>> {
>>> "test1": "local,clang-3.5,i386",
>>> "test2": "local,clang-3.5,x86_64",
>>> "test3": "local,totclang,i386",
>>> "test4": "local,totclang,x86_64",
>>> "test5": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,i386",
>>> "test6": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,x86_64"
>>> }
>>> but a single test line would probably be enough for you.
>>> Then, the master will invoke a script "test.sh" with the test config
>>> argument: (e.g., ./test.sh local,clang-3.5,i386) and your script should
>>> run the tests.
>>>
>>> let me know if you run into problems,
>>> pl
>>
>> lldb-amd64-ninja-netbsd8 [kernel ABI version 7.99.70] is up and running
>>
>> lldb-amd64-ninja-netbsd7 has been upgraded to 7.99.70 and restarted
>>
>> I switched the old machine to the staging buildfarm, set runTest=True in
>> buildbot/osuosl/master/config/builders.py and added the following
>> test_cfg.json:
>>
>> $ cat ./build/build/test_cfg.json
>> {
>> "test1": "local,gcc,x86_64",
>> }
>>
>> As of now it does not attempt to run the regression tests. Perhaps we
>> need to restart buildmaster configuration? I will ask Galina for it.
>>




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

I put a summary of April achievements here:

http://blog.netbsd.org/tnf/entry/lldb_netbsd_process_plugin_enhancements

The plan for the next milestone is continuing development of threads in
the NetBSD Process Plugin. I will need to work more on correctness of
ptrace(2) calls as new issues were detected in setups with threads that
resulted in crashes.

There is also ongoing work on a new build node running NetBSD-current
(prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling
unit tests to catch functional regressions quickly. The original LLDB
node cluster was privately funded by myself in the last two years and
has been switched to a machine hosted by The NetBSD Foundation.

To keep this machine up and running (8 CPU, 24 GB RAM) community support
through donations is required. This is crucial to actively maintain the
LLVM toolchain (Clang, LLDB and others) on NetBSD.




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] NetBSD core(5) files for LLDB's test-suite

[Kamil Rytarowski via lldb-dev]

On 02.05.2017 16:50, Pavel Labath wrote:
> Sorry it took me so long. I think it's fine to check a couple of those
> in. When zipped, they will still be orders of magnitude smaller then
> the windows minidump exe we are carrying around.
> 
> For the long term though, I'd like to add the necessary support to
> llvm's obj2yaml to be able to generate these. As far as I can tell, it
> just needs program header support added. Then we will be able to
> generate truly small unit tests (e.g. by removing all the memory
> segments for tests that only need threads signal or registers and
> such).

Sounds good with obj2yaml.

I'm willing to contribute needed code parts in obj2yaml when needed.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

On 02.05.2017 21:48, Christos Zoulas wrote:
> On May 2,  9:06pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: LLDB/NetBSD May
> 
> | I put a summary of April achievements here:
> | 
> | http://blog.netbsd.org/tnf/entry/lldb_netbsd_process_plugin_enhancements
> 
> Thanks, that looks great.
> 
> | The plan for the next milestone is continuing development of threads in
> | the NetBSD Process Plugin. I will need to work more on correctness of
> | ptrace(2) calls as new issues were detected in setups with threads that
> | resulted in crashes.
> 
> Makes sense. I will try to help.
>  

I built the kernel with all debug options and diagnostics.. and the
crashes disappeared.

On the other hand with these options enabled "resume1" started to fail,
a test from our ATF regression unit tests in t_ptrace_wait*.

There are two bugs:
 1. kernel crashes with threads in the local copy of Process Plugin.
 2. PT_SUSPEND, PT_RESUME unreliable http://gnats.netbsd.org/51995

I'm working on (1.) now.

If possible please help with (2.) as there are ATF tests ready and no
need to setup LLVM+Clang+LLDB.

Index: GENERIC
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.457
diff -u -r1.457 GENERIC
--- GENERIC 18 Apr 2017 19:09:12 -  1.457
+++ GENERIC 2 May 2017 19:57:36 -
@@ -91,14 +91,14 @@
 # Diagnostic/debugging support options
 optionsDIAGNOSTIC  # inexpensive kernel consistency checks
# XXX to be commented out on release branch
-#options   DEBUG   # expensive debugging checks/support
-#options   LOCKDEBUG   # expensive locking checks/support
+optionsDEBUG   # expensive debugging checks/support
+optionsLOCKDEBUG   # expensive locking checks/support

 #
 # Because gcc omits the frame pointer for any -O level, the line below
 # is needed to make backtraces in DDB work.
 #
-makeoptionsCOPTS="-O2 -fno-omit-frame-pointer"
+makeoptionsCOPTS="-O0 -g -fno-inline -fno-omit-frame-pointer"
 optionsDDB # in-kernel debugger
 #options   DDB_COMMANDONENTER="bt" # execute command when ddb is entered
 #options   DDB_ONPANIC=1   # see also sysctl(7): `ddb.onpanic'


> | There is also ongoing work on a new build node running NetBSD-current
> | (prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling
> | unit tests to catch functional regressions quickly. The original LLDB
> | node cluster was privately funded by myself in the last two years and
> | has been switched to a machine hosted by The NetBSD Foundation.
> | 
> | To keep this machine up and running (8 CPU, 24 GB RAM) community support
> | through donations is required. This is crucial to actively maintain the
> | LLVM toolchain (Clang, LLDB and others) on NetBSD.
> 
> Why don't we run this in one of our machines?
> 

It's already there! (talia.netbsd.org)

For details there is need to talk our admins.

> christos
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

On 02.05.2017 22:04, Kamil Rytarowski wrote:
> 
> There are two bugs:
>  1. kernel crashes with threads in the local copy of Process Plugin.
>  2. PT_SUSPEND, PT_RESUME unreliable http://gnats.netbsd.org/51995
> 
> I'm working on (1.) now.
> 
> If possible please help with (2.) as there are ATF tests ready and no
> need to setup LLVM+Clang+LLDB.
> 

A.
I had to downgrade llvm/clang/lldb to pkgsrc-wip r. cf22065aaf016 to
reproduce the crash again (LLVM SVN r.300853). It was hidden with recent
failures for 400 tests for some other unknown reason.

The crash has been fixed with src/sys/kern/sys_ptrace_common.c r1.22

B.
I'm still verifying single stepping of LWPs in processes with multiple
threads. I have an impression that something is fragile there.

C.
LLDB tests trigger dmesg errors (default GENERIC kernel), there are
entries like:
fill_vmentry: vp 0xfe87288967e8 error 2
fill_vmentry: vp 0xfe86e1a15930 error 2
fill_vmentry: vp 0xfe87047f8bd8 error 2
fill_vmentry: vp 0xfe87051af7e0 error 2
fill_vmentry: vp 0xfe86ef0b63f0 error 2

D.
Once the above points will be so sorted out, I will move to the recent
failure that broke tests in LLDB on NetBSD. And next I will work on
watchpoint misbehavior (they are reported like PT_STEP).

Additionally something (related?) recently keeps ejecting the NetBSD
builder in the farm node as it timeouts (?).

We need to sort out all that before pushing forwards the NetBSD Process
Plugin with threads in LLDB.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

On 03.05.2017 23:10, Christos Zoulas wrote:
> On May 3, 10:25pm, n...@gmx.com (Kamil Rytarowski) wrote:
> | B.
> | I'm still verifying single stepping of LWPs in processes with multiple
> | threads. I have an impression that something is fragile there.
> 
> Ok. Let me know when you have a reproducible problem...
> 

The problem looks similar to PT_RESUME and PT_SUSPEND (per-LWP operations).

With multiple LWPs after creation of a thread followed by raising a
signal for the tracer, a process cannot be singlestepped as one thread
apparently never starts or dies (?) and _lwp_wait() (for reasonable
value of lwpid_t: 2) returns EDEADLK.

_lwp_makecontext()
_lwp_create()
raise(signal)
_lwp_wait()

This is not restricted to PT_SETSTEP, the same happens with PT_STEP.

I will go into this rabbit hole and debug it till squashing the bug.
It will take a while, but getting understanding what's going on is
beneficial (besides profit of just correcting it).

There was filed another report for PT_RESUME... there is tension from
the community:

"Several ptrace_wait test cases fail under DEBUG+LOCKDEBUG"
http://gnats.netbsd.org/52213

> | C.
> | LLDB tests trigger dmesg errors (default GENERIC kernel), there are
> | entries like:
> | fill_vmentry: vp 0xfe87288967e8 error 2
> | fill_vmentry: vp 0xfe86e1a15930 error 2
> | fill_vmentry: vp 0xfe87047f8bd8 error 2
> | fill_vmentry: vp 0xfe87051af7e0 error 2
> | fill_vmentry: vp 0xfe86ef0b63f0 error 2
> 
> This is DIAGNOSTIC and it is tangentially related to your favorite
> friend (F_GETPATH) :-)
> 
> Let me explain what's wrong here. Getting from a file descriptor
> to a vnode is always a success (if the file descriptor refers to one)
> (vp is the pointer to a vnode here).
> Getting from a vnode to a path is not (here you get 2 ENOENT from
> vnode_to_path):
> 
> 1. The file is removed so there is no path (what I suspect is happening here).
> 2. There are more than one paths and it is not deterministic which one you get
>(usually does not matter, but it does when you don't have permission to
> get to the one returned but you have to the other)
> 3. vnode_to_path() uses the reverse-namei cache to do its deed. This can
>lose in 2 different ways:
>   - cache eviction: not really an issue unless there is memory pressure
> (still need to handle it, but infrequent).
>   - path component length... The dreaded NCHNAMLEN (31) constant which
> is the component namelength limit for the current namei cache
> implementation (we should really fix that one day).
> 
> This is why I keep saying forget adding F_GETPATH unless you can make it
> work reliably first :-)
> 

Thank you for the analysis. These reports aren't fatal to the stability
of the system. Once I will sort out the noise from tests, I will have a
closer look at this.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-server tests

[Kamil Rytarowski via lldb-dev]

Thank you for this work.

I will add a usual requirement - please make sure that "check-lldb-unit"
works in standalone builds.

On 15.05.2017 16:33, Pavel Labath wrote:
> Hello all,
> 
> In case you haven't noticed it, I'd like to draw your attention to
> D32930, where we're proposing a new test framework for lldb-server
> tests. The discussion has so far been about low-level implementation
> details, so you don't have to read through it if you don't feel like
> to (but I do encourage it)
> 
> However, I'd like to explain some of the high-level motivations which
> led to our proposed design and open a discussion on them here. I'll do
> this in an FAQ form: :)
> 
> - why new framework?:
> 
> Lldb-server tests were never really suited for the dotest.py model
> anyway (for example they end up creating an SBDebugger, only to be
> completely ignoring it and opening a socket connection to lldb-server
> directly). Perhaps for this reason, they are also harder to write than
> usual lldb tests, and a lot more messy internally (e.g., after Chris's
> ipv6 patch, which caused all lldb-server connections in the test to
> fail, I've learned that the test harness will attempt the lldb-server
> connection 400(!!!) times before conceding defeat). The test suite
> operation is also very illogical when it comes to doing remote tests:
> to test lldb-server on a remote target, you first have to build
> lldb-server for the target, THEN you have to build lldb for the HOST,
> and THEN you run dotest.py in the HOST build folder while passing
> funny dotest.py arguments.
> 
> 
> - why lldb-server ?:
> We'd like this to be a first step in porting the existing test off of
> the dotest.py test runner. Unlike the full test suite, the number of
> lldb-server tests is not that big, so porting them is an task
> achievable in a not too long timeframe, and it can serve as a proof of
> concept when considering further steps. Also, lldb-server already
> performs a relatively well-defined and simple task, which means it
> fits the llvm model of testing isolated components of functionality
> without the need for a massive refactor.
> 
> - why c++ (aka, if the existing test suite is broken, why not just fix it) ?:
> There are two fundamental issues with the current test suite which
> cannot be easily "fixed". The first one is the remote execution (which
> is where a large part of the test harness complexity comes from). By
> writing the test in c++ we can run the test *and* lldb-server remotely
> (***), avoiding the network communication and flakyness that comes
> with it. The other issue is the fact that it needs to have a
> completely independent reimplementation of the gdb-remote protocol.
> Sure, some duplication is expected from tests, but it does not have to
> be that big. If we write the test in c++ we can reuse parts of the
> gdb-remote client code (thereby increasing test coverage of that as
> well), and only resort to manual packet parsing when we really want to
> (e.g., when testing the server response to a malformed packet or
> similar).
> 
> - ok, but why not have the test described by a text file, and have a
> c++ FileCheck-like utility which interprets it?:
> Due to the unpredictable (e.g. we cannot control the addresses of
> objects in the inferior), and interactive nature of the tests, we
> believe they would be easier to write imperatively, instead of a more
> declarative FileCheck style. E.g. for one test you need to send
> qRegisterInfoN for N=1,... until you find the pc register then pluck a
> field with that number from a stop-reply packet, and compare that the
> result of another packet, while possible reversing endianness. To
> describe something like this in a text file, you will either need
> primitives to describe loops, conditionals, etc (which will then tend
> towards implementing a full scripting language), or have a very
> high-level primitive operation which does exactly this, which will
> tend towards having many specialized primitive operations.
> 
> regards,
> pavel
> 
> (***) To achieve this, we want to propose adding the ability to
> execute tests remotely to llvm-lit, which we hope will be useful to
> more people. I'll write more about this in a separate email with
> llvm-dev included.
> 





signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB: Sanitizing the debugger's runtime

[Kamil Rytarowski via lldb-dev]

Hello,

I posted the LLDB/NetBSD report for May:

https://blog.netbsd.org/tnf/entry/lldb_sanitizing_the_debugger_s

I'm heading now to get the LLVM sanitizers aboard and use them for
further development of the LLDB/NetBSD port.

I need to modify the whole stack of LLVM (llvm, clang, compiler-rt,
libsanitizer). I prepared environment to execute tests in LLVM and Clang
and they appear to be in acceptable shape now to move on to sanitizers.

LLVM:
  Expected Passes: 13216
  Expected Failures  : 107
  Unsupported Tests  : 7242
  Unexpected Failures: 252

Clang:
  Expected Passes: 9847
  Expected Failures  : 14
  Unsupported Tests  : 876
  Unexpected Failures: 2

This work is sponsored by The NetBSD Foundation.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB: Sanitizing the debugger's runtime

[Kamil Rytarowski via lldb-dev]

On 06.06.2017 17:47, Kamil Rytarowski wrote:
> Hello,
> 

Hello,

Short update.

> I posted the LLDB/NetBSD report for May:
> 
> https://blog.netbsd.org/tnf/entry/lldb_sanitizing_the_debugger_s
> 
> I'm heading now to get the LLVM sanitizers aboard and use them for
> further development of the LLDB/NetBSD port.
> 
> I need to modify the whole stack of LLVM (llvm, clang, compiler-rt,
> libsanitizer). I prepared environment to execute tests in LLVM and Clang
> and they appear to be in acceptable shape now to move on to sanitizers.
> 

LLVM asan and ubsan on NetBSD
http://blog.netbsd.org/tnf/entry/llvm_asan_and_ubsan_on

Roadmap for the next month:
 - Send upstream LLVM asan and ubsan support.
 - Correct more problems triggered by LLVM and Clang test-suites.
 - Resume msan and tsan porting.

> LLVM:
>   Expected Passes: 13216
>   Expected Failures  : 107
>   Unsupported Tests  : 7242
>   Unexpected Failures: 252
> 

I fixed 20 failures with the implementation of NetBSD specific PaX
MPROTECT allocator for RWX regions.

> Clang:
>   Expected Passes: 9847
>   Expected Failures  : 14
>   Unsupported Tests  : 876
>   Unexpected Failures: 2
> 
> This work is sponsored by The NetBSD Foundation.
> 





signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB: Sanitizing the debugger's runtime

[Kamil Rytarowski via lldb-dev]

On 03.07.2017 18:41, Kamil Rytarowski wrote:
> On 06.06.2017 17:47, Kamil Rytarowski wrote:
>> Hello,
>>
> 
> Hello,
> 
> Short update.
> 
>> I posted the LLDB/NetBSD report for May:
>>
>> https://blog.netbsd.org/tnf/entry/lldb_sanitizing_the_debugger_s
>>
>> I'm heading now to get the LLVM sanitizers aboard and use them for
>> further development of the LLDB/NetBSD port.
>>
>> I need to modify the whole stack of LLVM (llvm, clang, compiler-rt,
>> libsanitizer). I prepared environment to execute tests in LLVM and Clang
>> and they appear to be in acceptable shape now to move on to sanitizers.
>>
> 
> LLVM asan and ubsan on NetBSD
> http://blog.netbsd.org/tnf/entry/llvm_asan_and_ubsan_on
> 
> Roadmap for the next month:
>  - Send upstream LLVM asan and ubsan support.
>  - Correct more problems triggered by LLVM and Clang test-suites.
>  - Resume msan and tsan porting.
> 

http://blog.netbsd.org/tnf/entry/llvm_clang_and_compiler_rt

I will continue during August the same tasks.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [5.0.0 Release] Please help fix the remaining blockers (2 days left!)

[Kamil Rytarowski via lldb-dev]

On 22.08.2017 01:36, Hans Wennborg via llvm-dev wrote:
> Hello everyone,
> 
> According to the release schedule, we're supposed to be tagging
> 'final' on Wednesday. Unfortunately, I suspect we will be a little
> late.
> 
> There are currently 32 open release blockers:
> https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_format=advanced&resolution=---
> 
> Some of those have traction, but many don't. Some just need bisection,
> checking if the issue still reproduces, etc.
> 
> Please help take a look at the bugs in that list. It would be really
> great if we could drive it down to zero blockers and tag rc3 by the
> end of the week.
> 

It would be nice to backport this patch as is to 5.0.0.

"Use sys::Memory::AllocateRWX for JIT code"
https://reviews.llvm.org/D35558

It JIT unbreaks code for NetBSD-8.x.

A proper solution, to revamp the JIT code, with a better API is under
development and should land LLVM-6.0.0.

> Many thanks,
> Hans
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM libFuzzer and SafeStack ported to NetBSD

[Kamil Rytarowski via lldb-dev]

Hello,

I've prepared a summary of the last month:

http://blog.netbsd.org/tnf/entry/llvm_libfuzzer_and_safestack_ported

This month I will not work on a new development and I will focus on
relax and taking part in EuroBSDcon in Paris. I will speak about the
LLDB porting to NetBSD.

Long-term goals are finishing the basis sanitizers (msan, tsan) and
switching back to LLDB porting. The sanitizers will be used to develop
and debug the LLVM debugger. There is also integration with sanitizers
in LLDB.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] EuroBSDcon2017 - The LLDB Debugger on NetBSD

[Kamil Rytarowski via lldb-dev]

Hello,

I've uploaded my slides from the EuroBSDcon 2017 event about:

   "The LLDB Debugger on NetBSD"

to:

   http://netbsd.org/~kamil/eurobsdcon2017.html

There is a recording available on YouTube:

   https://youtu.be/qX0BS4P65cQ?t=16835



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] EuroBSDcon2017 - The LLDB Debugger on NetBSD

[Kamil Rytarowski via lldb-dev]

On 26.09.2017 19:15, Kamil Rytarowski wrote:
> Hello,
> 
> I've uploaded my slides from the EuroBSDcon 2017 event about:
> 
>"The LLDB Debugger on NetBSD"
> 
> to:
> 
>http://netbsd.org/~kamil/eurobsdcon2017.html
> 
> There is a recording available on YouTube:
> 
>https://youtu.be/qX0BS4P65cQ?t=16835
> 


https://blog.netbsd.org/tnf/entry/eurobsdcon_2017_paris_report

Plan for the next milestone:

Resume porting tsan and msan to NetBSD with a plan to switch back to the
LLDB porting.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] One year checkpoint and Thread Sanitizer update

[Kamil Rytarowski via lldb-dev]

The past year has been started with bugfixes and the development of
regression tests for ptrace(2) and related kernel features, as well as
the continuation of bringing LLDB support and LLVM sanitizers (ASan +
UBsan and partial TSan + Msan) to NetBSD.
My plan for the next year is to finish implementing TSan and MSan
support, followed by a long run of bug fixes for LLDB, ptrace(2), and
other related kernel subsystems

http://blog.netbsd.org/tnf/entry/one_year_checkpoint_and_thread

Plans for the next milestone

The general goals are to finish TSan and MSan and switch back to LLDB
debugging. I plan to verify the impact of the TSan bootstrap
initialization on the observed crashes and research the remaining failures.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any
donations to help us continue funding projects and services to the
open-source community. Please consider visiting the following URL, and
chip in what you can:

http://netbsd.org/donations/#how-to-donate



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Sanitizers update: The LLVM Thread Sanitizer has been ported to NetBSD

[Kamil Rytarowski via lldb-dev]

Hello,

I've finished the LLVM TSan porting:

https://blog.netbsd.org/tnf/entry/the_llvm_thread_sanitizer_has

Next goal:
Finish MSan followed by the switch to LLDB/NetBSD corrections.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Sanitizers update: The LLVM Thread Sanitizer has been ported to NetBSD

[Kamil Rytarowski via lldb-dev]

Yes, I can run LLDB under at least ASan and TSan.

Pity, the backend part (lldb-server) broke after refactoring the code in
recent months. I'm observing an early NULL pointer deference from NetBSD
Process Plugin - this is unrelated to the previous stability bugs that
inspired me to get the sanitizers aboard.

I will be back to LLDB once I will finish MSan.

On 30.11.2017 21:27, Zachary Turner wrote:
> Have you been able to run lldb under any sanitizers yet?
> On Thu, Nov 30, 2017 at 12:24 PM Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Hello,
> 
> I've finished the LLVM TSan porting:
> 
> https://blog.netbsd.org/tnf/entry/the_llvm_thread_sanitizer_has
> 
> Next goal:
> Finish MSan followed by the switch to LLDB/NetBSD corrections.
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] The LLVM Memory Sanitizer support work in progress

[Kamil Rytarowski via lldb-dev]

I've prepared a report of the past month on MSan:

https://blog.netbsd.org/tnf/entry/the_llvm_memory_sanitizer_support

This is work in progress and I will keep working on MSan. I can already
sanitize trivial programs, but not the larger ones. Sanitizing
LLDB/NetBSD with MSan is still distant.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] The LLVM Sanitizers stage accomplished

[Kamil Rytarowski via lldb-dev]

I've finished the interruption for LLVM Sanitizers:

http://blog.netbsd.org/tnf/entry/the_llvm_sanitizers_stage_accomplished


Plan for the next milestone:

Keep upstreaming a pile of local compiler-rt patches.
Restore the LLDB support for traced programs with a single thread.


This work was sponsored by .



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The LLVM Sanitizers stage accomplished

[Kamil Rytarowski via lldb-dev]

Thanks!

The general goal of mine with the LLVM & surrounding work is to turn on
all the features and to enable the execution of regular tests.

Building and testing LLDB or other software, on a buildbot, under LLVM
Sanitizers has not been planned and is beyond the scope with the current
resources.

I must mention that it is possible and it would be a great goal to
achieve. First we would need to accomplish the goals mentioned in the
blog entry "Future directions and goals". In general while in the
current GNU/Linux distributions it's non-trivial to integrate sanitizers
(see:
http://dev.chromium.org/developers/testing/instrumented-libraries-for-dynamic-tools
or https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo
) it's relatively simple in an Operating System distribution such as NetBSD.

Just turn a global distribution option like "MKSANITIZER=Thread" or
"MemoryWithOrigins", build the userland and we are ready to go. To name
a few dependencies of LLDB will get ready to use out-of-the-box
libraries for *San: -lkvm, -ledit, -lterminfo, -lcurses, -lform,
-lpanel, -lz, -lelf, -l[std]c++, -lpython, -lxml.

Getting this finished is a lot of work in the current circumstances and
if we could get interest and help (namely more people aboard working on
it) from e.g. Chromium guys to build such infrastructure - I will ensure
to make it happen.

On 01.02.2018 18:09, Zachary Turner wrote:
> Great work.  Have you tried (or considered) setting up an LLDB buildbot
> that runs the LLDB test suite with all of the sanitizers turned on?
> 
> On Thu, Feb 1, 2018 at 5:39 AM Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> I've finished the interruption for LLVM Sanitizers:
> 
> http://blog.netbsd.org/tnf/entry/the_llvm_sanitizers_stage_accomplished
> 
> 
> Plan for the next milestone:
> 
> Keep upstreaming a pile of local compiler-rt patches.
> Restore the LLDB support for traced programs with a single thread.
> 
> 
> This work was sponsored by .
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [6.0.0 Release] TIme to wrap it up

[Kamil Rytarowski via lldb-dev]

On 19.02.2018 16:57, Hans Wennborg via lldb-dev wrote:
> I would also like to get the release notes ready this week. If you've
> been meaning to write something but didn't get around to it yet, now
> is the time.
> 

Notes regarding the X86(_64) backend: Preliminary support for Sanitizers
and sibling features on NetBSD (ASan, UBsan, TSan, MSan, SafeStack,
libFuzzer).

Feel free to improve the wording.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB/NetBSD - Status February 2018

[Kamil Rytarowski via lldb-dev]

I've managed to unbreak the LLDB debugger as much as possible with the
current kernel and hit problems with ptrace(2) that are causing issues
with further work on proper NetBSD support. Meanwhile, I've upstreamed
all the planned NetBSD patches to sanitizers and helped other BSDs to
gain better or initial support.

http://blog.netbsd.org/tnf/entry/lldb_restoration_and_return_to

Plan for the next milestone

With the approaching NetBSD 8.0 release I plan to finish backporting a
few changes there from HEAD:

 - Remove one unused feature from ptrace(2), PT_SET_SIGMASK &
PT_GET_SIGMASK. I've originally introduced these operations with
criu/rr-like software in mind, but they are misusing or even abusing
ptrace(2) and are not regular process debuggers. I plan to remove this
operation from HEAD and backport this to NetBSD-8(BETA), before the
release, so no compat will be required for this call. Future ports of
criu/rr should involve dedicated kernel support for such requirements.
 - Finish the backport of _UC_MACHINE_FP() to NetBSD-8. This will allow
use of the same code in sanitizers in HEAD and NetBSD-8.0.
 - By popular demand, improve the regnsub(3) and regasub(3) API, adding
support for more or less substitutions than 10.

Once done, I will return to ptrace(2) debugging and corrections.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] NetBSD ptrace(2) hardening status

[Kamil Rytarowski via lldb-dev]

I've spent a month on fixes and debugging issues around the tracing
facilities in the kernel.

Plan for the next milestone

Keep working on the bug reproducible with X86 Debug Registers and switch
to the remaining ptrace(2) failures.

http://blog.netbsd.org/tnf/entry/struggling_to_fix_a_bohrbug



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Forking fixes in the context of debuggers

[Kamil Rytarowski via lldb-dev]

For the past month I've been mostly working on improving the kernel code
in the ptrace(2) API. Additionally, I've prepared support for reading
NetBSD/aarch64 core(5) files.

A critical Problem Report kern/51630 regarding lack of PTRACE_VFORK
implementation has been fixed. This means that there are no other
unimplemented API calls, but there are still bugs in the existing ones.

With fixes and addition of new test cases, as of today we are passing
961 ptrace(2) tests and skipping 1 (out of 1018 total).

Plan for the next milestone

Cover the remaining forking corner-cases in the context of debuggers
with new ATF tests and fix the remaining bugs.

The first step is to implement proper support for handling
PT_TRACE_ME-traced scenarios from a vfork(2)ed child. Next I plan to
keep covering the corner cases of the forking code and finish this by
removal of subtle bugs that are still left in the code since the
SMP'ification.

http://blog.netbsd.org/tnf/entry/forking_fixes_in_the_context

This work was sponsored by The NetBSD Foundation.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB/NetBSD report May/2018: Coverage of signal routines in the kernel in the context of ptrace(2)

[Kamil Rytarowski via lldb-dev]

The number of ATF ptrace(2) tests cases has been significantly
incremented, however there is still a substantial amount of work to be
done and a number of serious bugs to be resolved.

With fixes and addition of new test cases, as of today we are passing
1,206 (last month: 961) ptrace(2) tests and skipping 1 (out of 1,256
total; last month: 1,018 total). No counted here tests that appeared
outside the ptrace(2) context.


Plan for the next milestone:

Cover with regression tests remaining elementary scenarios of handling
crash signals. Fix known bugs in the NetBSD kernel.

Follow up the process with the remaining fork(2) and vfork(2) scenarios.

This work was sponsored by The NetBSD Foundation.

http://blog.netbsd.org/tnf/entry/coverage_of_signal_routines_in



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB/NetBSD - Status June 2018

[Kamil Rytarowski via lldb-dev]

MKSANITIZER - bug detector software integration with the NetBSD userland

I've finished the integration of sanitizers with the distribution build
framework. A bootable and installable distribution is now available,
verified with Address Sanitizer, with Undefined Behavior Sanitizer, or
with both concurrently. A few dozen bugs were detected and the majority
of them addressed.


Plan for the next milestone

The ptrace(2) tasks have been preempted by the suspended work on
sanitizers, in order to actively collaborate with the Google Summer of
Code students (libFuzzer integration with userland, KUBSan, KASan).

I have planned the following tasks before returning back to the
ptrace(2) fixes:

 * upgrade base Clang/LLVM, libcxx, libcxxabi to at least 7svn (HEAD)
(needs cooperation with Joerg Sonnenberger)
 * compiler-rt import and integration with base (needs cooperation with
Joerg Sonnenberger)
 * merge TSan, MSan and libFuzzer ATF tests
 * prepare MKSANITIZER readme
 * kernel-asan port
 * kernel-ubsan port
 * switch syscall(2)/__syscall(2) to libc calls
 * upstream local patches, mostly to compiler-rt
 * develop fts(3) interceptors (MSan, for ls(1), find(1), mtree(8)
 * investigate and address the libcxx failing tests on NetBSD
 * no-ASLR boot.cfg option, required for MKSANITIZER

My plan for the next milestone is to reduce the the list and keep
actively collaborating with the summer students.


http://blog.netbsd.org/tnf/entry/mksanitizer_bug_detector_software_integration


This work was sponsored by The NetBSD Foundation.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [8.0.0 Release] Release schedule

[Kamil Rytarowski via lldb-dev]

On 03.12.2018 14:04, Hans Wennborg via lldb-dev wrote:
> Hello everyone,
> 
> I know 7.0.1 isn't out the door yet, and 8.0.0 isn't due for a while,
> so relax :-) But I would like to get the schedule decided before folks
> disappear over the holidays.
> 
> According to the usual schedule, the branch would be created two weeks
> into January, with the goal of shipping early March, so this is my
> proposal:
> 
> - 16 January 2019: Create the 8.0.0 branch, RC1 tagged soon after.
> 
> - 6 February, RC2 tag.
> 
> - 27 February, Final tag, release shipping a few days after.
> 
> What do you think, especially release testers?
> 

From NetBSD point of view Jan 16th is good. Earlier date would be nervous.

> For the 6.0.0 release, the branch was created earlier in January after
> a request from the community. This time I haven't heard anything, but
> please let me know if a different schedule would be better for you.
> 
> Ideally I'd like to finalize and post the schedule by the end of the week.
> 
> Thanks,
> Hans
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 





signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 29.10.2019 21:40, Christos Zoulas wrote:
> On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
> 
> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
> | > 
> | > I investigated the bug yesterday, and filled some of my discoveries in
> | > 
> | >  https://bugs.llvm.org/show_bug.cgi?id=43830
> | > 
> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.
> | 
> | Hey Christos,
> | 
> | could I bother you to take a look at this python PR 
> | , and the related lldb bug 
> | ?
> | 
> | The executive summary is that there is an incompatibility between 
> | readline and its libedit emulation, which python needs to work around. 
> | Is there any way this can be fixed in libedit?
> | 
> | I guess the presence of the workaround will make the fix tricky, because 
> | then the workaround will be wrong for the "fixed" libedit, but it's 
> | still probably worth it to try to resolve this somehow.
> | 
> | WDYT?
> 
> I don't know what I have to do here. Can someone explain to me what the
> issue is?
> 
> christos
> 

Is this a packaging issue? There are good reasons to use libedit as a
gnu readline replacement. I am not sure how complete it is here, but
there is definitely better licensing (at least from the GPLv3 vs GPLv2
incompatibility point of view - certain projects must use one version,
others the other one). If there are some nits in the readline compat,
better to fix the editline code for general benefit.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 30.10.2019 11:06, Pavel Labath wrote:
> On 29/10/2019 21:40, Christos Zoulas wrote:
>> On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
>> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
>>
>> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
>> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
>> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
>> | >
>> | > I investigated the bug yesterday, and filled some of my
>> discoveries in
>> | >
>> | >  https://bugs.llvm.org/show_bug.cgi?id=43830
>> | >
>> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's
>> a mess.
>> |
>> | Hey Christos,
>> |
>> | could I bother you to take a look at this python PR
>> | , and the related lldb
>> bug
>> | ?
>> |
>> | The executive summary is that there is an incompatibility between
>> | readline and its libedit emulation, which python needs to work around.
>> | Is there any way this can be fixed in libedit?
>> |
>> | I guess the presence of the workaround will make the fix tricky,
>> because
>> | then the workaround will be wrong for the "fixed" libedit, but it's
>> | still probably worth it to try to resolve this somehow.
>> |
>> | WDYT?
>>
>> I don't know what I have to do here. Can someone explain to me what the
>> issue is?
> 
> I haven't dug into this (maybe Serge can explain in more detail), but I
> think this comment (Modules/readline.c in python sources) gives a
> general overview of the problem. Ignore the "On OSX" part, the same
> should apply to any OS.
> 
> /*
>  * It is possible to link the readline module to the readline
>  * emulation library of editline/libedit.
>  *
>  * On OSX this emulation library is not 100% API compatible
>  * with the "real" readline and cannot be detected at compile-time,
>  * hence we use a runtime check to detect if we're using libedit
>  *
>  * Currently there is one known API incompatibility:
>  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
>  *   index with older versions of libedit's emulation.
>  * - Note that replace_history and remove_history use a 0-based index
>  *   with both implementations.
>  */
> 
> Furthermore, you can probably look at every instance of
> if(using_libedit_emulation) in that file (or via this link
> ),
> as each one indicates a workaround for some libedit incompatibility. It
> looks like not all of them are still relevant, as it seems some of them
> are there just for the sake of old libedit bugs which have since been
> fixed, but it looks like at least some of them are. Serge, can you tell
> what exactly was the problem which caused the crash?
> 
> pl

Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Kamil Rytarowski via lldb-dev]

Python is in general a no-go for a BSD basesystem (micropython can be an
exception.. but Python is so large today that we can reevaluate this
statement at some point). This is why we need to either disable certain
features in LLDB or split LLDB between everything without Python in the
base and the rest (like data formatters) through 3rd party packaging system.

Once we will finish our goals for LLDB/NetBSD we will work on this
separation in order to include LLDB in the basesystem.

Lua is a part of the NetBSD and FreeBSD basesystem so all the scripting
issues can be gone. I cannot speak for Darwin or Windows basesystem, but
I can imagine that Lua is a smaller issue than Python.

Personally, I am interested in another [today] niche scripting language
(Tcl), but adding Lua support should make LLDB easier for scripting in
general. Switching Lua bindings to other language is simple, so this is
another benefit in my eyes, especially since Python bindings are machine
generated today.

On 09.12.2019 10:57, Pavel Labath via lldb-dev wrote:
> I think this would be a very interesting project, and would allow us to
> flesh out the details of the script interpreter interface.
> 
> A lot of the complexity in our python code comes from the fact that
> python can be (a) embedded into lldb and (b) lldb can be embedded into
> python. It's been a while since I worked with lua, but from what I
> remember, lua was designed to make (a) easy., and I don't think (b) was
> ever a major goal (though it can always be done ways, of course)..
> 
> Were you intending to implement both of these directions or just one of
> them ((a), I guess)?
> 
> The reason I am asking this is because doing only (a) will definitely
> make lua support simpler than python, but it will also mean it won't be
> a "python-lite".
> 
> Both of these options are fine -- I just want to understand where you're
> going with this. It also has some impact on the testing strategy, as our
> existing python tests are largely using mode (b).
> 
> Another question I'm interested in is how deeply will this
> multi-interpreter thing go? Will it be a build time option, will it be
> selectable at runtime, but we'll have only one script interpreter per
> SBDebugger, or will we be able to freely mix'n'match scripting languages?
> 
> I think the last option would be best because of data formatters
> (otherwise one would have a problem is some of his data formatters are
> written in python and others in lua), but it would also create a lot
> more of new api surface, as one would have to worry about consistency of
> the lua and python views of lldb, etc.
> 
> On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
>> Hi everyone,
>>
>> Earlier this year, when I was working on the Python script
>> interpreter, I thought it would be interesting to see what it would
>> take to support other scripting languages in LLDB. Lua, being designed
>> to be embedded, quickly came to mind. The idea remained in the back of
>> my head, but I never really got around to it, until now.
>>
>> I was pleasantly surprised to see that it only took me a few hours to
>> create a basic but working prototype. It supports running single
>> commands as well as an interactive interpreter and has access to most
>> of the SB API through bindings generated by SWIG. Of course it's far
>> from complete.
>>
>> Before I invest more time in this, I'm curious to hear what the
>> community thinks about adding support for another scripting language
>> to LLDB. Do we need both Lua and Python?
>>
>> Here are some of the reasons off the top of my head as to why the
>> answer might be
>> "yes":
>>
>>  - The cost for having another scripting language is pretty small. The
>> Lua script interpreter is very simple and SWIG can reuse the existing
>> interfaces to generate the bindings.
>>  - LLDB is designed to support multiple script interpreters, but in
>> reality we only have one. Actually exercising this property ensures
>> that we don't unintentionally break that design assumptions.
>>  - The Python script interpreter is complex. It's hard to figure out
>> what's really needed to support another language. The Lua script
>> interpreter on the other hand is pretty straightforward. Common code
>> can be shared by both.
>>  - Currently Python support is disabled for some targets, like Android
>> and iOS. Lua could enable scripting for these environments where
>> having all of Python is overkill or undesirable.
>>
>> Reasons why the answer might be "no":
>>
>>  - Are our users going to use this?
>>  - Supporting Python is an ongoing pain. Do we really want to risk
>> burdening ourselves with another scripting language?
>>  - The Python API is very well tested. We'd need to add test for the
>> Lua bindings as well. It's unlikely this will match the coverage of
>> Python, and probably even undesirable, because what's the point of
>> testing the same thing twice. Also, do we want to risk fragmenting
>> tests across two scripting

[lldb-dev] Preliminary support for NetBSD

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I'm working on the NetBSD support for LLDB/LLVM. My current status is
that it already builds and runs with my local patches. Unfortunatelly
it still doesn't work due to (at least) ptrace(2) differences with the
FreeBSD code.

I would like to submit the current platform support for review and to
be integrated with lldb.

Tracing current changes and constant rebasing few kLOC patch is
time-costy and heavy for me, I would like to continue development and
research how to replace the missing bits from ptrace(2) in the NetBSD
kernel, perhaps by expanding it with extra capabilities and altering
the existing code within the current diff with later patches.

What do you think?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDI0pAAoJEEuzCOmwLnZsrKwQAKb09v/iQM+kco2bpjhmjyet
ezs4oQYMltolbJ0LV7s8rXDl8ROYrmOv2nH39xAwsuGh1XpWq7dzDkzXQXBdr9QG
6lovV/s5+x33SETAQhwTL/fQMhZ/vgrx3SX1lssRVEnHjs6XWRz2rMlX3ITNkOMp
CWJV7iwiz+ErsOgYTszbC+yKIcKhFWInLy+Rkl7KyGiXv4AF1ibm+8SsHWXbBdyJ
AqQTX1tJgLq8Zu8++yLQBwK76gUqq5zOBCwUjgqss3fWALD095HtDhwB7WgRTFUe
wdZtnuy2dfxfTDveEgsbSbHCZs27sIFaOLdE0M1rO/+vDfEctecoMqKByl60hfiD
ZmUaFsmdXCQX6kWDY7SJOYWIQcVcSF9rRgpCauat8+Eg+QSB1D6dWHrCEI3jYUm9
Al8J8lEkWqStB1DioKjq2CeXlPpuLmv+hCrXRHmUCuKG30/WdrroXVTNnwcRTfoi
S7Uc8gU/NJiBE9+6+DK5i8hInv1W9sBbICngE33bPRc1JRCNWW5SEWfuYu2HTI3B
oMl0b4IU56yYrGfMclKL44GO6h3hjh2ENEEiN9BOYKx1TJQ/hFeIQ8FUHd6slSng
cs1qVDAMTYORrlXiomtopxFCXMfVWXkFfkjNz1lAE5LpxERsrkipCx0IrMc0dpea
PmaCrpffOR790FbG3zhH
=V8fI
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Preliminary support for NetBSD

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05.10.2015 21:46, Todd Fiala wrote:
> Seems like a great idea.  (Ed, is that something you might be able
> to review?)
> 

The first patch is already proposed:
http://reviews.llvm.org/D13334

> Hopefully you have access to other platforms to test if it's
> breaking anything?  (Most likely candidates would be FreeBSD and
> Linux/Android, I'd suspect, depending on how much you're having to
> change things).
> 

I just run just NetBSD exclusively (desktop, development). My Linux or
FreeBSD (unlikely frequent) is limited and at that places I don't
develop lldb. I don't remember when I touched other systems, perhaps
Tru64 2 years ago.

It's not that crucial anyway, as there is review board.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWFkOfAAoJEEuzCOmwLnZslOYQAICJ/lnkehumJOD8TQ7NfPvD
XZXI2Y/AuXRNbCbDHp1LxCmY8ZrVkdJrGEttpKQhS53UgYHWEzd6jZlt+tQE5qmW
pMr7p+oEK58q6ui1igDUw+Qr+RFHzjNjPuaAu4tnnO7UmU94kSlrrRcsnEIbALcu
Rdj9K4dlysZlvepm7ogAP8kGE9tzRb0+2S0wJHFLvseesShMeqiDrZuH+6WGrh4K
KZNfL1rU307Va79Q/mx1ENyjSHjUkSOLR1teMvecSl3sIZVN920arGcXojSN4lcP
U53Lb7v5ngPnhIzyQ3DP2IC3SSyBppOqeJsdZtEoGIdizK3p91YhRbKccDUA37VV
G2QlSy8wl2tFf4yPoE+ZDUslGImvj8b9ovSR5sbLNVD128XrV5OpuO7G7WIB/xJK
RHBOijyfb99sVxq3F83jHsCKBqB1okuf9GekCfaN5/GMFt7WMaPoJloCFD/UkMfZ
lo/kwVYc3FOrrIBhA1vLWwKBq1NxaZBvFDcq7t57kfJan2B/g0fV3zYBdrdFfsbw
qzdDJSCoqr5LMucKJYQDJX9W4XODpSZFOGPcm7hd3mr7jMl6ysEHCXUDzOzYDw4w
tKYMj6Y8+Ad6n7pWKNh2AqcfYF3FoXTm9Y0nprN0HrLkqVRnJKWwz4PTSAN25tdN
/JTt8lARs1ngXwR2KzfU
=1FhT
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Does anyone depend on using LLDB with Python 2.6?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

(NetBSD) Python 2.6 was retired with pkgsrc-2015Q2

http://mail-index.netbsd.org/pkgsrc-users/2015/07/06/msg021778.html

On 19.10.2015 21:43, Zachary Turner via lldb-dev wrote:
> AKA: Is Python 2.6 a supported configuration?  I found this 
> `argparse_compat.py` file in tests, and it opens with this:
> 
> """ Compatibility module to use the lldb test-suite with Python
> 2.6.
> 
> Warning: This may be buggy. It has not been extensively tested and 
> should only be used when it is impossible to use a newer Python
> version. It is also a special-purpose class for lldb's test-suite. 
> """
> 
> import sys
> 
> if sys.version_info >= (2, 7): raise "This module shouldn't be used
> when argparse is available (Python >= 2.7)" else: print("Using
> Python 2.6 compatibility layer. Some command line options may not
> be supported")
> 
> 
> 
> 
> ___ lldb-dev mailing
> list lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWJVOYAAoJEEuzCOmwLnZs/jAQAIUkbz/C7AkSfRGkaCDYKuGk
d6lY2eXIBM+KYWTsVsWiqzJgMyokcz8P1lF9YCD1hyKiNqSMeHA0h3qYHzfQKsli
GwT3e0eebVQjPdQTv8DrdaVWUq3nwvUFhYEzFaUP3HaIMmp0B1lZILjXL66XXrvv
bhxmJlFFQX9qgREHy1UYIfctHxyWXjIT82iw13CVGgXMEXdcwZH3Hbt/XZuhDICL
Be4n6Ht5sVbqE59Gucc0quioPMlnnvsJiIMoCggeryeBFvmrxsf0R6yecn7h+Evr
hROGapryC0hCu+B+p+1dtN56Eg4ZbqthQas6dDe0lSuohcsarE/tz5HS5rrDPNV0
Mec4cIDBIFWjESAGyVvy9CBz9qmMUy52Q6BzKTJwUgGb2fqcb7pYu6iwjXzIzCvn
y4dvIfo8nQJbo6q7rJyYpn5Pz3WCGAQEioZCGj6RN2XCIDvdHYMDXk40vq/kmCzt
O6uSSyrmtLxfoEcCt77FIsXPqA81z0gaZ4Q+Hp2kT848RX5xXSNEAfIpYBW8WfNX
34VmP5nc/cqnJHzAc/AZlcikWpuSl4bkjimK8YOHK8+Yt1qgxs5rREtJaGrcfRpK
2DVS9zuDXOdw3Fm8v7u5fzg0erWKeOtHLujt/wtDwpvMfWLm1RY+g46P2kPx21bk
bNGm/EoPIhvD57akpem8
=maz/
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Preliminary support for NetBSD

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08.10.2015 12:21, Kamil Rytarowski via lldb-dev wrote:
> On 05.10.2015 21:46, Todd Fiala wrote:
>> Seems like a great idea.  (Ed, is that something you might be
>> able to review?)
> 
> 
> The first patch is already proposed: 
> http://reviews.llvm.org/D13334
> 
>> Hopefully you have access to other platforms to test if it's 
>> breaking anything?  (Most likely candidates would be FreeBSD and 
>> Linux/Android, I'd suspect, depending on how much you're having
>> to change things).
> 
> 
> I just run just NetBSD exclusively (desktop, development). My Linux
> or FreeBSD (unlikely frequent) is limited and at that places I
> don't develop lldb. I don't remember when I touched other systems,
> perhaps Tru64 2 years ago.
> 
> It's not that crucial anyway, as there is review board.

There is buildslave with NetBSD-7.0 in the gates. When it will be
functional, I will switch it immediately to the master lldb buildzone.

For now, I will disable running tests as I need to upstream few
plugins for NetBSD first.

Please review and merge the NetBSD pending commits in LLVM's
Phabricator, they are making it buildable for NetBSD - otherwise there
will be waste of an extra machine over there...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ21HAAoJEEuzCOmwLnZsLlIQAMApPBYE285ss6lg/qF2n9iK
KSx/+NwVtbebBbcAAB+ZBtNWAsMMS4o1Q6leII2/BDhx42/3sowo/xzPaO4FmyKy
WwiCSVJuCvvlnGbz0Nizm78124LrVn0CJOIzGEpYaQMVGLEoB1z7Kwa9kKQ0FUzZ
Tdj87SbUBr2BLQeHC2CoC3Xg5S5odAXdY4E6IRmBQruEjpxc0GpSlQ8PVGrsC6Mw
zGBBRet3NLAOfTrLvJ10SqhvXSgLvXldky9YX8o/ir651+UOrQ+4RbFZJz2gHELo
pB9AgkC+gDeJJEAZ5Ba4KpsDWqrljELnCiEHjVHiGBLSiqtcrwN4IzN1PVNM2gzs
+0RMs0vdqiHGSJS5mYItoOgoh00RXHT2BagoizvFJikrt/FtLrgLhTQtmQN7h4UT
ld69bhWc+nMSDzuavuw7auLEQKdLTzyqP2KhvOBvMKHUXE6ypQmgF3DIIkQOLZwL
prDHZLScDMLUgiJgN5EL8espMoT8WLPBjJViO9tNoHkcgAHfSGAe0pVwTHHbxns+
+Hf3N4BoVnGcao9jtox7NyU+DLq1OYdbBZgHhNWi1pYw/lffGmlnef6Zptts/Uko
4/gdbvabhDQg/Bw4K/xskPz+2strKHNBnBrlqrQ8JlqmRVAR5zWdJFeAgqotmUsS
15UU5VD+Ahji5BRa3v+P
=pfNe
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Preliminary support for NetBSD

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21.10.2015 12:47, Kamil Rytarowski via lldb-dev wrote:
> On 08.10.2015 12:21, Kamil Rytarowski via lldb-dev wrote:
>> On 05.10.2015 21:46, Todd Fiala wrote:
>>> Seems like a great idea.  (Ed, is that something you might be 
>>> able to review?)
> 
> 
>> The first patch is already proposed: 
>> http://reviews.llvm.org/D13334
> 
>>> Hopefully you have access to other platforms to test if it's 
>>> breaking anything?  (Most likely candidates would be FreeBSD
>>> and Linux/Android, I'd suspect, depending on how much you're
>>> having to change things).
> 
> 
>> I just run just NetBSD exclusively (desktop, development). My
>> Linux or FreeBSD (unlikely frequent) is limited and at that
>> places I don't develop lldb. I don't remember when I touched
>> other systems, perhaps Tru64 2 years ago.
> 
>> It's not that crucial anyway, as there is review board.
> 
> There is buildslave with NetBSD-7.0 in the gates. When it will be 
> functional, I will switch it immediately to the master lldb
> buildzone.
> 
> For now, I will disable running tests as I need to upstream few 
> plugins for NetBSD first.
> 
> Please review and merge the NetBSD pending commits in LLVM's 
> Phabricator, they are making it buildable for NetBSD - otherwise
> there will be waste of an extra machine over there...

The NetBSD buildslave is now operational

http://lab.llvm.org:8014/builders/lldb-amd64-ninja-netbsd7

Once it will finish building properly I will move it from the staging
buildmaster to the primary one.

At the moment it stops on:
http://reviews.llvm.org/D12995
http://reviews.llvm.org/D12994
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWKA/6AAoJEEuzCOmwLnZsblYP/1MFCdPqG/wLjv8Jxc9B7Nwf
zCmIC3iP10HYcqubep84m5eeUsoIo9+dDZGSHKGGj3XUiEyzUWruFFAulEHR9bGh
MPbb7dZQD0+XNq5KiUiGBBh3dl75qo47AgoMttQJAaJFTPCaE+c5r9Q50hceGaB/
KX8cNuoJ1nnUtoev1VaMN9fNS0WqDZtGjTcS+jTosGD524vXcv56/029Jic2aKtW
w63RR5RlHCmpzB/XUyYjap/mxlwni49lU5bFr93tZNGXu99KBsNm2z01jhfXQvv+
Sc5e7s7nhUf0Bzo+Hnx04m/pzDKz5b8WJRS0iIgHBwNErfgtjxLgRea8CdVS326H
tUv3pLc5GQXBYXCPsqCwFMNkTl7DZpHDQiUoP0O+QTyGZkM/BXgC37kF98kztLrl
YoL+EwdoioMwmt9yQCQzD87lPh3Q7gteM0a3EsQYV3FcxEFVeznZVMGVKsEH6xjo
zi5Zxiy7I1F28wrJIhPcukEoLTVxFZPP8YkCB+GkF9qTiyJFuCfsuQc62PH6+nkb
NhxVGZzgWtshK72gWGAk7vlhaL+ceJgY7nz3U8iwlDnWqs3YY90auwPZbSne9axZ
ZCFBB5d+oP/d0GA7bf+ZN6vfWX0TLnQ3tpAxXzR7XKeowyThBayuSvB9IDTxpZI6
LeJWovIz5hhWiYnH2x0A
=L5IT
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev