[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: ABI support for special memory area
On Thu, Feb 23, 2017 at 4:55 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/23/2017 11:19 AM, H.J. Lu wrote:
>> A system may have MCDRAM or other types of memory in addition to
>> normal RAM. Here is an ABI proposal to allow placement in a section
>> whose sh_info field indicates the special memory type.
>>
>> Any comments?
>>
>> H.J.
>> ---
>> To section attributes, add
>>
>> #define SHF_GNU_MBIND 0x00100000
>>
>> for sections used to place data or text into a special memory area.
>> The section names should start with ".mbind" so that they won't be
>> grouped together with normal sections by link editor. The sh_info
>> field indicates the special memory type.
>>
>> To the "Program Header" section, add an inclusive range of segment types
>> for GNU_MBIND segments:
>>
>> #define PT_GNU_MBIND_NUM 4096
>> #define PT_GNU_MBIND_LO (PT_LOOS + 0x474e555)
>> #define PT_GNU_MBIND_HI (PT_GNU_MBIND_LO + PT_GNU_MBIND_NUM - 1)
>>
>> The array element specifies the location and size of a special memory area.
>> Each GNU_MBIND segment contains one GNU_MBIND section and the segment
>> type is PT_GNU_MBIND_LO plus the sh_info value. If the sh_info value is
>> greater than PT_GNU_MBIND_NUM, no GNU_MBIND segment will be created. Each
>> GNU_MBIND segment must be aligned at page boundary. The interpretation of
>> the special memory area information is implementation-dependent.
>> Implementations may ignore GNU_MBIND segment.
>>
>> Run-time support
>>
>> int __gnu_mbind_setup (unsigned int type, void *addr, size_t length);
>>
>> It sets up special memory area of 'type' and 'length' at 'addr' where
>> 'addr' is a multiple of page size. It returns zero for success, positive
>> value of ERRNO for non-fatal error and negative value of ERRNO for fatal
>> error.
>>
>> After all shared objects and the executable file are loaded, relocations
>> are processed, for each GNU_MBIND segment in a shared object or the
>> executable file, run-time loader calls __gnu_mbind_setup with type,
>> address and length. The default implementation of __gnu_mbind_setup is
>
> Why does it run _after_ all shared objects and the executable file are loaded?
Since __gnu_mbind_setup may call any external functions, it can only
be done after everything is loaded and relocated.
> Why not let the dynamic loader choose when it needs to setup the memory?
1. We want to be able to add support for new type memory by just
updating the run-time library of __gnu_mbind_setup, instead of
updating glibc.
2. Since __gnu_mbind_setup may depend on other libraries, we
don't want a simple executable requires libfoo and libbar, in addition
to glibc, nor make libfoo and libbar part of glibc.
>> int
>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length)
>> {
>> return 0;
>> }
>>
>> which can be overridden by a different implementation at link-time.
>
> What if you _can't_ bind at ADDR?
It happens on systems without special memory. __gnu_mbind_setup
returns a positive value and ld.so keeps going.
> What if the binding would work if ADD was any value?
>
GNU_MBIND isn't a LOAD segment, similar to GNU_RELRO:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x54624 0x54624 R E 0x1000
LOAD 0x054e9c 0x00055e9c 0x00055e9c 0x001b0 0x001b8 RW 0x1000
DYNAMIC 0x054eac 0x00055eac 0x00055eac 0x00110 0x00110 RW 0x4
NOTE 0x000114 0x00000114 0x00000114 0x00044 0x00044 R 0x4
GNU_EH_FRAME 0x048eb8 0x00048eb8 0x00048eb8 0x00ff4 0x00ff4 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x054e9c 0x00055e9c 0x00055e9c 0x00164 0x00164 R 0x1
ADDR contains the start of a memory region within the LOAD segment.
--
H.J.