[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 <gclayton at apple.com> wrote:

>
> > On Aug 9, 2016, at 9:01 AM, Abhishek Aggarwal via lldb-dev <
> lldb-dev at 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 at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160810/f286e837/attachment-0001.html>