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 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.

  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)?

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.

Thanks
Abhishek Aggarwal

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?

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.

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

Hi Greg

My comments are inlined: