> On Aug 9, 2016, at 9:01 AM, Abhishek Aggarwal via lldb-dev
> <[email protected]> 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?
>
> 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
>
>
> Thanks
> Abhishek Aggarwal
>
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
