Hi Greg My comments are inlined:
On Tue, Aug 9, 2016 at 7:01 PM, Greg Clayton <gclay...@apple.com> 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
