Chris Johns commented on a discussion on cpukit/libdl/rtl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/679#note_129393 > +void* > +rtems_rtl_obj_base_address (const rtems_rtl_obj* obj) > +{ > + void* base = NULL; > + > + if (obj->text_base) > + base = obj->text_base; > + > + if (obj->data_base && (!base || obj->data_base < base)) > + base = obj->data_base; > + > + if (obj->bss_base && (!base || obj->bss_base < base)) > + base = obj->bss_base; > + > + if (obj->const_base && (!base || obj->const_base < base)) > + base = obj->const_base; I do not think it is as simple as this and from my brief reading of the standard for `dladdr` it says the "base of the address range occupied by the mapped object" and here things get murky. What does "object" refer too? The object file or the object referenced by the symbol? Does the standard assume the object file occupies a continuous region of the address space? In RTEMS users can provide `libdl` with a custom allocator and they could separate the the classes of memory into separate regions of the address space. A use case is the text and const data live in sections of memory that is read only while data and bss memory are placed in read/write sections of the address space. These may not be continuous or even close. It depends on the MMU hardware which in turn depends on the CPU architecture. Would the value be better if it is based on the symbol type? That is, if the input address is a function symbol so present in text section `text_base` is returned? @joel do you have a better understanding of the intent of the standard here? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/679#note_129393 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
