Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

Yep totally fine, I figured it out in real time ;-) Thanks! -Todd On Tue, Aug 9, 2016 at 6:05 PM, Zachary Turner wrote: > Sorry about that, yes I did a global search and replace since there were a > few hundred instances > > On Tue, Aug 9, 2016 at 6:01 PM Todd Fiala wrote: > >> I got it fixed

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

Sorry about that, yes I did a global search and replace since there were a few hundred instances On Tue, Aug 9, 2016 at 6:01 PM Todd Fiala wrote: > I got it fixed up. > > On Tue, Aug 9, 2016 at 5:59 PM, Todd Fiala wrote: > >> We don't link in LLVM in debugserver, so this part probably just needs

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

I got it fixed up. On Tue, Aug 9, 2016 at 5:59 PM, Todd Fiala wrote: > We don't link in LLVM in debugserver, so this part probably just needs to > go back to what it was before. > > On Tue, Aug 9, 2016 at 5:57 PM, Todd Fiala wrote: > >> (Did you do a global search and replace, and maybe we just

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

We don't link in LLVM in debugserver, so this part probably just needs to go back to what it was before. On Tue, Aug 9, 2016 at 5:57 PM, Todd Fiala wrote: > (Did you do a global search and replace, and maybe we just need a new > include here?) > > On Tue, Aug 9, 2016 at 5:55 PM, Todd Fiala wrot

Re: [lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

(Did you do a global search and replace, and maybe we just need a new include here?) On Tue, Aug 9, 2016 at 5:55 PM, Todd Fiala wrote: > Hi Zachary, > > I've got the latest LLVM and clang updated, and I'm trying to build > debugserver in svn trunk. It's failing on these two calls which looks li

[lldb-dev] LLVM_PRETTY_FUNCTION in RNBRemote.cpp?

Hi Zachary, I've got the latest LLVM and clang updated, and I'm trying to build debugserver in svn trunk. It's failing on these two calls which looks like you modified last today: DNBLogThreadedIf (LOG_RNB_REMOTE, "%s", LLVM_PRETTY_FUNCTION); /Users/tfiala/src/ lldb-llvm.org/lldb/tools/debu

[lldb-dev] Some thought on LLDB Evolution: Good Citizenship in the LLVM Community

Hi! I'd like to propose couple of topics on "Good Citizenship in the LLVM Community": 1) LLDB developers should participate in release process. Process of LLDB release validation is unclear. At least there are no LLDB binaries in http://llvm.org/pre-releases/3.9.0/rc1/clang+llvm-3.9.0-rc1-x86_64

[lldb-dev] CORRECTION: LLDB Evolution

Note that step 5 below is wildly inaccurate, a placeholder while drafting the note. The actual command to reformat should be: find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.cpp" \) -exec clang-format -i {} + If you’re curious where the longest lines in the original or resulting source

Re: [lldb-dev] LLDB Evolution

Standardizing include order would really help. LLVM's style is documented here , but to quote it: 1. Main Module Header 2. Local/Private Headers 3. llvm/... 4. System #includes So perhaps it would be reasonable for us to stand

Re: [lldb-dev] LLDB Evolution

Agreed that better layering and modularization is a worthwhile longer-term goal. These kinds of changes should be researched and proposed for discussion because code reorganization can be extremely disruptive (which is why we opened this comment period for the proposed reformatting!) I’d gener

Re: [lldb-dev] LLDB Evolution

Great catch! If refactoring along those lines doesn’t clean up 100% of the cases then it’s worth explicitly breaking up groups of #include directives with comments. clang-format won’t reorder any non-contiguous groups and it’s a great way to explicitly call out dependencies. Ideally we should

Re: [lldb-dev] LLDB Evolution

I ran clang-format and tried to build and got a bunch of compiler errors. Most of them are order of include errors. I fixed everything in the attached patch. I doubt this will apply cleanly for anyone unless you are at the exact same revision as me, but at least you can look at it and get an idea

Re: [lldb-dev] LLDB Evolution

Another thing worth thinking about for the long term is library layering and breaking the massive dependency cycle in LLDB. Every library currently depends on every other library. This isn't good for build times, code size, or reusability (especially where size matters like in lldb-server). I thi

Re: [lldb-dev] Loadable Code Segment Information & SectionType in LLDB

> On Aug 9, 2016, at 9:01 AM, Abhishek Aggarwal via lldb-dev > wrote: > > Hello all > > I have following 2 queries: > > 1. Can SB APIs of LLDB provide information regarding the loadable Code > Segment (r-xp part of /proc/$PID/maps file in case of Linux) of a debugged > process? The informat

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: > > *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

Re: [lldb-dev] LLDB Evolution

09.08.2016, 18:42, "Zachary Turner via lldb-dev" : > There are a lot of reasons for the lack of tests.  Off the top of my head, > two of the biggest ones are: > > 1) Some areas of LLDB have been historically hard to test.  The unwinder and > core dumps come to mind.  You can't really just check

Re: [lldb-dev] LLDB Evolution

I fully welcome this move and agree with the timeline. Woohoo. I also agree with assessment of the situation regarding testing. I think we're going to need to devote thought to testing if we're going to move closer towards llvm. pl On 9 August 2016 at 16:42, Zachary Turner via lldb-dev wrote: >

[lldb-dev] Loadable Code Segment Information & SectionType in LLDB

Hello all I have following 2 queries: 1. Can SB APIs of LLDB provide information regarding the loadable *Code Segment* (r-xp part of /proc/$PID/maps file in case of Linux) of a debugged process? The information I am looking for is start address and end address of the loadable code segment of the

Re: [lldb-dev] LLDB Evolution

There are a lot of reasons for the lack of tests. Off the top of my head, two of the biggest ones are: 1) Some areas of LLDB have been historically hard to test. The unwinder and core dumps come to mind. You can't really just check in an 800MB core dump into the repo. 2) Tests are very heavywei