Re: [lldb-dev] First hand support for musl-libc
Hi, thanks for the patch. I took the opportunity to clean up the code there, so I have committed a somewhat modified version, but I believe you should get the result you were trying to achieve. Let me know how it works. cheers, pl On 2 August 2016 at 13:53, Dangling Pointer via lldb-dev wrote: > Hi, > > > To build lldb 3.8 on Alpine Linux, this tiny patch is required: > https://github.com/alpinelinux/aports/blob/master/testing/lldb/lldb-3.8-alpine.patch > > Can anyone here please upstream it? Note that it doesn't break Android build > as in case of both bionic and musl, __GLIBC__ macro is undefined. > > > ___ > 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] Leaks from static variables
> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev > wrote: > > Hi lldb-dev, > > It looks like the debugger initializes static variables in llvm (see: > SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up. > > Does this cause memory leaks? I'd assumed that it's necessary to call > llvm_shutdown() somewhere to avoid this kind of leak. We can add it. Since LLDB.framework is a shared library, we should add this to the SystemInitializerFull::Terminate() function and see how things go. > Is there a buildbot I can check that tests an address-sanitized version of > lldb? I am not sure if we have one. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB Evolution
LLDB has come a long way since the project was first announced. As a robust
debugger for C-family languages and Swift, LLDB is constantly in use by
millions of developers. It has also become a foundation for bringing up
debugger support for other languages like Go and RenderScript. In addition to
the original macOS implementation the Linux LLDB port is in active use and
Windows support has made significant strides. IDE and editor integration via
both SB APIs and MI have made LLDB available to even more users. It’s
definitely a project every contributor can be proud of and I’d like to take a
moment to thank everyone who has been involved in one way or another.
It’s also a project that shows some signs of strain due to its rapid growth.
We’ve accumulated some technical debt that must be paid off, and in general it
seems like a good time to reflect on where we'll be headed next. We’ve
outlined a few goals for discussion below as well as one more short-term
action. Discussion is very much encouraged.
Forward-Looking Goals
1. Testing Strategy Evaluation
Keeping our code base healthy is next to impossible without a robust testing
strategy. Our existing suite of tests is straightforward to run locally, and
serves as a foundation for continuous integration. That said, it is definitely
not exhaustive. Obvious priorities for improvement include gathering coverage
information, investing in more conventional unit tests in addition to the suite
of end-to-end tests, and introducing tests in code bases where we depend on
debugger-specific behavior (e.g.: for expression evaluation.)
2. C++ Module Support
LLDB takes advantage of Clang modules for type information and expression
evaluation. This has been used extensively for C and Objective-C scenarios,
but Clang C++ module support is now mature enough that we can extend our
support accordingly. Fully embracing C++ modules will enable LLDB expressions
to take advantage of template declarations and other constructs that are better
represented by declarations than the artifacts produced during compilation.
3. Establishing Language Integration Standards
As more languages build on LLDB’s foundation the project runs the risk of
growing deep dependencies on a wide variety of compilers and runtimes. The
community needs to engage in a constructive conversation about how best to keep
the core of LLDB clean and allow language support to be plugged in. Whether
this should occur at compile-time or runtime and how best to organize
repositories and branches to meet the needs of our diverse community will be an
ongoing topic of discussion.
4. Good Citizenship in the LLVM Community
Last, but definitely not least, LLDB should endeavor to be a good citizen of
the LLVM community. We should encourage developers to think of the technology
stack as a coherent effort, where common code should be introduced at an
appropriate level in the stack. Opportunities to factor reusable aspects of
the LLDB code base up the stack into LLVM will be pursued.
One arbitrary source of inconsistency at present is LLDB’s coding standard.
That brings us to…
Near-Term Goal: Standardizing on LLVM-style clang-format Rules
We’ve heard from several in the community that would prefer to have a single
code formatting style to further unify the two code bases. Using clang-format
with the default LLVM conventions would simplify code migration, editor
configuration, and coding habits for developers who work in multiple LLVM
projects. There are non-trivial implications to reformatting a code base with
this much history. It can obfuscate history and impact downstream projects by
complicating merges. Ideally, it should be done once with as much advance
notice as is practical. Here’s the timeline we’re proposing:
Today - mechanical reformatting proposed, comment period begins
To get a preview of what straightforward reformatting of the code looks like,
just follow these steps to get a clean copy of the repository and reformat it:
Check out a clean copy of the existing repository
Edit .clang-format in the root of the tree, remove all but the line
“BasedOnStyle: LLVM”
Change your current working directory to the root of the tree to reformat
Double-check to make sure you did step 3 ;-)
Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format
-i {} +"
Aug 20th - comment period closes, final schedule proposed
TBD (early September?) - patches land in svn
The purpose of the comment period is to review the straightforward diffs to
identify areas where comment pragmas should be used to avoid undesirable
formatting (tables laid out in code are a classic example.) It’s also a time
when feedback on the final timetable can be discussed, and any unforeseen
implications can be discovered. We understand that LLDB tends toward
relatively long names that may not always work well with the LLVM convention of
wrapping
Re: [lldb-dev] LLDB Evolution
On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev < lldb-dev@lists.llvm.org> wrote: > LLDB has come a long way since the project was first announced. As a > robust debugger for C-family languages and Swift, LLDB is constantly in use > by millions of developers. It has also become a foundation for bringing up > debugger support for other languages like Go and RenderScript. In addition > to the original macOS implementation the Linux LLDB port is in active use > and Windows support has made significant strides. IDE and editor > integration via both SB APIs and MI have made LLDB available to even more > users. It’s definitely a project every contributor can be proud of and I’d > like to take a moment to thank everyone who has been involved in one way or > another. > > It’s also a project that shows some signs of strain due to its rapid > growth. We’ve accumulated some technical debt that must be paid off, and > in general it seems like a good time to reflect on where we'll be headed > next. We’ve outlined a few goals for discussion below as well as one more > short-term action. Discussion is very much encouraged. > > *Forward-Looking Goals* > >1. Testing Strategy Evaluation > > Keeping our code base healthy is next to impossible without a robust > testing strategy. Our existing suite of tests is straightforward to run > locally, and serves as a foundation for continuous integration. That said, > it is definitely not exhaustive. Obvious priorities for improvement > include gathering coverage information, investing in more conventional unit > tests in addition to the suite of end-to-end tests, and introducing tests > in code bases where we depend on debugger-specific behavior (e.g.: for > expression evaluation.) > > I know this is going to be controversial, but I think we should at least do a serious evaluation of whether using the lit infrastructure would work for LLDB. Conventional wisdom is that it won't work because LLDB tests are fundamentally different than LLVM tests. I actually completely agree with the latter part. They are fundamentally different. However, we've seen some effort to move towards lldb inline tests, and in a sense that's conceptually exactly what lit tests are. My concern is that nobody with experience working on LLDB has a sufficient understanding of what lit is capable of to really figure this out. I know when I mentioned this some months ago Jonathan Roelofs chimed in and said that he believes lit is extensible enough to support LLDB's use case. The argument -- if I remember it correctly -- is that the traditional view of what a lit test (i.e. a sequence of commands that checks the output of a program against expected output) is one particular implementation of a lit-style test. But that you can make your own which do whatever you want. This would not just be busy work either. I think everyone involved with LLDB has experienced flakiness in the test suite. Sometimes it's flakiness in LLDB itself, but sometimes it is flakiness in the test infrastructure. It would be nice to completely eliminate one source of flakiness. I think it would be worth having some LLDB experts sit down in person with some lit experts and brainstorm ways to make LLDB use lit. Certainly it's worth a serious look, even if nothing comes of it. >4. Good Citizenship in the LLVM Community > > Last, but definitely not least, LLDB should endeavor to be a good citizen > of the LLVM community. We should encourage developers to think of the > technology stack as a coherent effort, where common code should be > introduced at an appropriate level in the stack. Opportunities to factor > reusable aspects of the LLDB code base up the stack into LLVM will be > pursued. > > One arbitrary source of inconsistency at present is LLDB’s coding > standard. That brings us to… > > *Near-Term Goal: Standardizing on LLVM-style clang-format Rules* > > We’ve heard from several in the community that would prefer to have a > single code formatting style to further unify the two code bases. Using > clang-format with the default LLVM conventions would simplify code > migration, editor configuration, and coding habits for developers who work > in multiple LLVM projects. There are non-trivial implications to > reformatting a code base with this much history. It can obfuscate history > and impact downstream projects by complicating merges. Ideally, it should > be done once with as much advance notice as is practical. Here’s the > timeline we’re proposing: > > *Today* - mechanical reformatting proposed, comment period begins > > To get a preview of what straightforward reformatting of the code looks > like, just follow these steps to get a clean copy of the repository and > reformat it: > > >1. Check out a clean copy of the existing repository >2. Edit .clang-format in the root of the tree, remove all but the line >“BasedOnStyle: LLVM” >3. Change your current working directory to the r
[lldb-dev] [Bug 28910] New: Add frame-finish breakpoints
https://llvm.org/bugs/show_bug.cgi?id=28910 Bug ID: 28910 Summary: Add frame-finish breakpoints Product: lldb Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: christian.con...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified It would be helpful for LLDB's Python API to provide a notification when a particular frame of interest is no longer on the call stack. The motivating use-case is a script which performs per-function-activation analysis, and needs to perform book-keeping when the function of interest is both activated and completed. These features in particular would be great: (a) Users have a reliable mechanism to correlate the activation and completion of each frame. (b) Sometimes a frame is completed not because it executed a "return" statement, but because of a C++ exception or a call to "longjmp". In these cases, it would be very helpful if the notification still occurred. Ideally the notification would occur before another call was made, on that same thread, to the function of interest. But it would still be useful if the notifications were deferred until the overall thread completed execution. (c) Performance is better than what one would get by having a script single-step through the inferior's execution, examining the state of the call stack after each step. RELATED WORK: (1) In a discussion on llvm-dev: http://lists.llvm.org/pipermail/lldb-dev/2016-August/010865.html , Jim Ingham provided a Python class which approximates the desired behavior. Casual testing on be a novice LLDB user (me) seems to show that his approach works for normal return paths, but does not detect frame-completions arising from "longjump" calls, as described above. The effect of C++ exceptions were not tested. (2) The lldb command "thread step-out" seems to behave similarly to (1) in the presence / absence of "longjmp" calls. (3) GDB provides a "finish" command, which attempts to resume execution (approximately) until the currently selected stack frame is complete. That gdb command seems equivalent to creating a 'gdb.FinishBreakpoint' object in gdb's Python API. Testing seems to show that 'gdb.FinishBreakpoint' objects do eventually get triggered even when a "longjmp" occurred, but perhaps not until the next time that thread's execution is paused. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution
FWIW, as a happy lldb user, it's exciting to read about these planned developments. I have two follow-up questions about the section on 'Testing Strategy Evaluation': (1) what is lldb's policy on including test updates with bug fix commits and functional changes, and (2) how is this policy enforced? AFAICT, it seems that lldb is not as strict about its test policy as other llvm sub-projects. That could be to its detriment. Here are some very rough numbers on the number of commits which include test updates [1]: - lldb: 287 of the past 1000 commits - llvm: 511 of the past 1000 commits - clang: 622 of the past 1000 commits - compiler-rt: 543 of the past 1000 commits NFC commits make these numbers a bit noisy. But, unless lldb has a much higher ratio of NFC commits to functional changes as compared to other llvm sub-projects, this is a concerning statistic. best, vedant [1] Based on ToT = r278069. HAS_TEST=0 TOTAL=1000 for HASH in $(git log --oneline -n$TOTAL | cut -d' ' -f1); do git show --stat $HASH | grep "|" | grep -q test && HAS_TEST=$((HAS_TEST+1)) done echo $HAS_TEST "/" $TOTAL > On Aug 8, 2016, at 2:57 PM, Zachary Turner via lldb-dev > wrote: > > > > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev > wrote: > LLDB has come a long way since the project was first announced. As a robust > debugger for C-family languages and Swift, LLDB is constantly in use by > millions of developers. It has also become a foundation for bringing up > debugger support for other languages like Go and RenderScript. In addition > to the original macOS implementation the Linux LLDB port is in active use and > Windows support has made significant strides. IDE and editor integration via > both SB APIs and MI have made LLDB available to even more users. It’s > definitely a project every contributor can be proud of and I’d like to take a > moment to thank everyone who has been involved in one way or another. > > It’s also a project that shows some signs of strain due to its rapid growth. > We’ve accumulated some technical debt that must be paid off, and in general > it seems like a good time to reflect on where we'll be headed next. We’ve > outlined a few goals for discussion below as well as one more short-term > action. Discussion is very much encouraged. > > Forward-Looking Goals > >1. Testing Strategy Evaluation > > Keeping our code base healthy is next to impossible without a robust testing > strategy. Our existing suite of tests is straightforward to run locally, and > serves as a foundation for continuous integration. That said, it is > definitely not exhaustive. Obvious priorities for improvement include > gathering coverage information, investing in more conventional unit tests in > addition to the suite of end-to-end tests, and introducing tests in code > bases where we depend on debugger-specific behavior (e.g.: for expression > evaluation.) > I know this is going to be controversial, but I think we should at least do a > serious evaluation of whether using the lit infrastructure would work for > LLDB. Conventional wisdom is that it won't work because LLDB tests are > fundamentally different than LLVM tests. I actually completely agree with > the latter part. They are fundamentally different. > > However, we've seen some effort to move towards lldb inline tests, and in a > sense that's conceptually exactly what lit tests are. My concern is that > nobody with experience working on LLDB has a sufficient understanding of what > lit is capable of to really figure this out. > > I know when I mentioned this some months ago Jonathan Roelofs chimed in and > said that he believes lit is extensible enough to support LLDB's use case. > The argument -- if I remember it correctly -- is that the traditional view of > what a lit test (i.e. a sequence of commands that checks the output of a > program against expected output) is one particular implementation of a > lit-style test. But that you can make your own which do whatever you want. > > This would not just be busy work either. I think everyone involved with LLDB > has experienced flakiness in the test suite. Sometimes it's flakiness in > LLDB itself, but sometimes it is flakiness in the test infrastructure. It > would be nice to completely eliminate one source of flakiness. > > I think it would be worth having some LLDB experts sit down in person with > some lit experts and brainstorm ways to make LLDB use lit. > > Certainly it's worth a serious look, even if nothing comes of it. > > >4. Good Citizenship in the LLVM Community > > Last, but definitely not least, LLDB should endeavor to be a good citizen of > the LLVM community. We should encourage developers to think of the > technology stack as a coherent effort, where common code should be introduced > at an appropriate level in the stack. Opportunities to factor reusable > aspects of the LLDB code base up the stack
