This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX


>>> On 08.08.13 at 02:33, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> We use the .gnu_attribute directive to record an object attribute:
> 
> enum
> {
>   Tag_GNU_X86_EXTERN_BRANCH = 4,
> };
> 
> for the types of external branch instructions in relocatable files.
> 
> enum
> {
>   /* All external branch instructions are legacy.  */
>   Val_GNU_X86_EXTERN_BRANCH_LEGACY = 0,
>   /* There is at lease one external branch instruction with BND prefix.  */
>   Val_GNU_X86_EXTERN_BRANCH_BND = 1,
> };
> 
> An x86 feature note section, .note.x86-feature, is used to indicate
> features in executables and shared library. The contents of this note
> section are:
> 
>     .section        .note.x86-feature
>     .align          4
>     .long           .L1 - .L0
>     .long           .L3 - .L2
>     .long           1
> .L0:
>     .asciz         "x86 feature"
> .L1:
>     .align          4
> .L2:
>     .long        FeatureFlag (Feature flag)
> .L3:
> 
> The current valid bits in FeatureFlag are
> 
> #define NT_X86_FEATURE_PLT_BND    (0x1 << 0)
> 
> It should be set if PLT entry has BND prefix to preserve bound registers.
> 
> The remaining bits in FeatureFlag are reserved.
> 
> When merging Tag_GNU_X86_EXTERN_BRANCH, if any input relocatable
> file has Tag_GNU_X86_EXTERN_BRANCH set to Val_GNU_X86_EXTERN_BRANCH_BND,
> the resulting Tag_GNU_X86_EXTERN_BRANCH value should be
> Val_GNU_X86_EXTERN_BRANCH_BND.
> 
> When generating executable or shared library, if PLT is needed and
> Tag_GNU_X86_EXTERN_BRANCH value is Val_GNU_X86_EXTERN_BRANCH_BND,
> the 32-byte PLT entry should be used and the feature note section should
> be generated with the NT_X86_FEATURE_PLT_BND bit set to 1 and the feature
> note section should be included in PT_NOTE segment. The benefit of the
> note section is it is backward compatible with existing run-time and tools.

While I can see the purpose of the attribute section, I don't see
what the note section is for: You don't mention at all what it's
consumed for, and I also can't see how it validly would be for
anything. That's because iirc note section contents, if not
understood by the consumer, is required to not have any effect
on the correctness of the program. Hence if loaded on a system
that MPX capable, has an MPX aware kernel, but no MPX aware
user space (apart from this one executable or shared library, or
a set thereof), it ought to still work correctly. Which - afaict - it
won't if the dynamic loader itself isn't MPX aware.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]