Re: nm not finding __objc_class names Re: Loading bundle resources using GNUstep runtime 2.0

[Patryk Laurent]

Hi David and Matt,

> On Feb 18, 2020, at 16:42, Matt Rice <ratmice@gmail.com> wrote:
> 
> On Mon, Feb 17, 2020 at 12:00 PM David Chisnall
> <gnustep@theravensnest.org> wrote:
>> 
>> Note that, if you want to enumerate all of the classes in a library, you
>> can do so on ELF platforms by using dl_iterate_phdr to find the
>> `__objc_classes` section in each loaded ELF image and collect the
>> classes directly (this section is an array of pointers to classes
>> declared in the ELF file).  This will work irrespective of build system goo.
>> 
>> On Windows, the corresponding section is `.objcrt$CLS` (though I believe
>> the CLS part is a sub-section and is stripped during linkage).
> 
> I believe that there is (or at least was) already dl_iterate_phdr,
> and that for some reason this was added to get the list of classes
> without actually loading
> the object file?  If that path still exists, its perhaps possible this
> series of issues, is people using this API,
> and calling frameworkClasses without causing the loading shared object.

It seems an important part of the process is to determine if the listed classes 
in are implemented elsewhere (eg., in a framework). These scripts determine 
this by checking the output for no for class names having a “U” next to them, 
in which case they are such “elsewhere” classes.  

Do the methods you are proposing inform on whether classes are implemented “in 
this module” versus “elsewhere”?

Thank you,
Patryk