Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

On Aug 9, 2016, at 8:42 AM, Zachary Turner via lldb-dev 
 wrote:
> #2 could potentially be improved by lit style tests.  

+1 to this.

> Again, the real question is just how much effort are we actually prepared to 
> put into this?  I'd love it if there were entire days or weeks that were just 
> testing weeks, where all we did was add new tests (or refactor code to make 
> it more testable) and people didn't work on anything else.  I've been 
> inactive for a while because I've had to prioritize work on some things in 
> LLVM, but I could make time for something like that.

I think it makes sense to start with the big mechanical changes and try to do 
it in a single “change the world” commit to avoid disrupting version control 
history too much.  After that is done, the many various refactorings (fixing 
dependence cycles, improving the testing situation to be more lit like, sinking 
functionality into LLVM and reusing existing LLVM functionality more, etc) can 
all be done in parallel and independently over time.

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> So perhaps it would be reasonable for us to standardize on something like 
> this:
> 
> Main Module Header
> Local/Private Headers
> lldb/...
> llvm/...
> System #includes

This makes sense to me, and matches what clang does as well.  I think that this 
is clearly in the spirit of the llvm include order standards, and I think it 
would be great to make this explicit in the coding standard doc.  Can you send 
in a patch to update it to make this explicit?  I’ll review it.

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

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Brian Cain via lldb-dev]

[earlier I had accidentally sent this message to only Hans, re-sending as
reply-all now]

When I tried rc1 on sles11.3 x86_64, msan's getrlimit test fails to build
for lack of prlimit().  SLES11.3 has glibc 2.11.3.  Is there a minimum
required glibc?  I think this test implementation previously used
getrlimit(), which is present on glibc2.11.3.



On Fri, Jul 29, 2016 at 5:57 PM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>



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

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

[Abhishek Aggarwal via lldb-dev]

Hi Greg

My comments are inlined:

On Tue, Aug 9, 2016 at 7:01 PM, Greg Clayton  wrote:

>
> > On Aug 9, 2016, at 9:01 AM, Abhishek Aggarwal via lldb-dev <
> lldb-dev@lists.llvm.org> 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 information I am looking for is start address and end address
> of the loadable code segment of the debugged process. I know that SBModule
> class can provide all the Sections of the object file via SBSection class.
> However, I couldn't find any API in this class that can provide the
> information I need.
>
> There can be many sections that contain code. I am not sure what you mean
> by "the loadable code segment of the debugged process". ".text" in ELF is
> just a section, but that doesn't mean that it will be the only section that
> contains code. Same goes for mach-o files. SBSection doesn't currently
> expose the permissions of sections, but we can easily add that since
> lldb_private::Section has permissions that I added about a month ago:
>
> //--
> /// Get the permissions as OR'ed bits from lldb::Permissions
> //--
> uint32_t
> lldb_private::Section::GetPermissions() const;
>
> //--
> /// Set the permissions using bits OR'ed from lldb::Permissions
> //--
> void
> lldb_private::Section::SetPermissions(uint32_t permissions);
>
> So I would think that you would want to iterate over the sections and
> check their permissions and use any that are read + execute from the main
> executable?
>
>
By "Loadable Code Segment" I wanted to refer to Segments of an elf file
having type PT_LOAD and containing executable machine instructions.
However, as you said I need all the sections that are read+execute. Thanks
for pointing about the permission API for sections. I can add an API of
getting Permissions to SBSection class and upload it for review soon.


> >
> > 2. SBSection::GetSectionType() API returns an enum 'SectionType'. Does
> SectionType represent the section types as specified by different object
> file formats (Mach-O, PECOFF, ELF)?
>
> It does in an agnostic way. You can watch for any sections that have
> eSectionTypeCode as their type from the main executable.
>
> >
> > As an example, ELF specification specifies section types like SHT_NULL,
> SHT_PROGBITS, SHT_RELA, SHT_HASH, SHT_NOTE, SHT_NOBITS etc. However,
> SectionType enum doesn't contain all these types. Hence, enum SectionType
> is either a mix of all section types of different object file formats or it
> is a custom type of LLDB. I will appreciate any comment on this.
>
> Again, we aren't trying to expose all of the different bits from ELF and
> Mach-o and COFF directly, we try to intelligently encapsulate the data by
> making more general definitions. If you feel that a SHT_XXX value should
> have its own new SectionType, we can discus that. The section type
> detections inside of ObjectFileELF is not that great, so feel free to
> improve the ObjectFileELF::CreateSections() function to "do the right
> thing". Anything that is SHT_PROGBITS should probably be eSectionTypeCode.
> It looks like just ".text" is being set to eSectionTypeCode right now.
>
>
This is what I wanted to confirm. I was not sure whether eSectionTypeCode
implies those sections which have read+execute permissions or those
sections that have  section type as SHT_PROGBITS (in case of ELF format).
Thanks for clarifying. I can try to fix it for
ObjectFileELF::CreateSections() function.


> As an example I would assume that:
>
> SHT_NULL -> eSectionTypeOther (if this section is even exposed, and I
> don't believe it is)
> SHT_PROGBITS -> eSectionTypeCode
> SHT_RELA -> eSectionTypeELFRelocationEntries (although these definition
> should never have had ELF in the name, these enums are supposed to be
> agnostic...)
> SHT_HASH -> eSectionTypeOther
> SHT_NOTE -> eSectionTypeOther
> SHT_NOBITS -> eSectionTypeOther
> >
> >
> > Thanks
> > Abhishek Aggarwal
> >
> >
> > ___
> > 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] LLDB Evolution

[Pavel Labath via lldb-dev]

I've started to do some cleanup of the include header order (r278222).
It doesn't get everything compiling after a clang-format, but it got
me about half way.

+1 on the include order proposed by Zach. I agree that better
modularization would improve testability and have a positive impact on
the size of lldb-server (e.g., right now we have to link it against
libclang, even though it shouldn't need any of that functionality).

pl

On 9 August 2016 at 23:01, Zachary Turner via lldb-dev
 wrote:
> Standardizing include order would really help.  LLVM's style is documented
> here, but to quote it:
>
> Main Module Header
> Local/Private Headers
> llvm/...
> System #includes
>
> So perhaps it would be reasonable for us to standardize on something like
> this:
>
> Main Module Header
> Local/Private Headers
> lldb/...
> llvm/...
> System #includes
>
> Putting LLDB headers before LLVM headers is a nice way to enforce "include
> what you use".  Otherwise you might have something like this:
>
> // lldb.cpp
> #include "llvm/LLVM1.h"
> #include "lldb/lldb2.h
>
> // lldb2.h
> llvm::MyType foo();
>
> And this will work, even though lldb2.h needs to have #include
> "llvm/LLVM1.h"
>
> So the above ordering fixes that.  clang-format won't solve this for us
> automatically, but it would be nice to at least move towards it.
>
> On Tue, Aug 9, 2016 at 2:49 PM Kate Stone  wrote:
>>
>> 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 be focused on committing changes along these lines so
>> that there’s no post-format tweaking required to build cleanly again.
>>
>> Kate Stone k8st...@apple.com
>>  Xcode Low Level Tools
>>
>> On Aug 9, 2016, at 1:03 PM, Zachary Turner  wrote:
>>
>> 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 of what had to change.
>>
>> The #include win32.h thing is really annoying and hard for people to
>> remember the right incantation.  I'm going to make a file called
>> Host/PosixApi.h which you can just include, no matter what platform you're
>> on, and everything will just work.  That should clean up a lot of this
>> nonsense.
>>
>> On Tue, Aug 9, 2016 at 11:10 AM Zachary Turner  wrote:
>>>
>>> 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 think
>>> the massive Python dependency was removed after my work earlier this year.
>>> But I'm not sure what the status of that is now, and there's still the rest
>>> of LLDB.
>>>
>>> In the future it would be nice to have a modules build of LLDB.  And
>>> sure, we could just have liblldb be one giant module, but that seems to kind
>>> of defeat the purpose of modules in the first place.
>>>
>>> For unit tests in particular, it's nice to be able to link in just the
>>> set of things you need, and that's difficult / impossible right now.
>>>
>>> On Tue, Aug 9, 2016 at 10:00 AM Zachary Turner 
>>> wrote:

 On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev
  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.  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