[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: ABI support for special memory area



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?

Why not let the dynamic loader choose when it needs to setup the memory?
 
> 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?

What if the binding would work if ADD was any value?

-- 
Cheers,
Carlos.