[PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization

[Andy Lutomirski]

On Wed, Jul 2, 2014 at 11:54 AM, Will Deacon <will.deacon at arm.com> wrote:
> Cheers for this, Andy.
>
> On Wed, Jul 02, 2014 at 07:34:22PM +0100, Andy Lutomirski wrote:
>> On Wed, Jul 2, 2014 at 10:24 AM, Will Deacon <will.deacon at arm.com> wrote:
>> > ELF Header:
>> >   Start of section headers:          1888 (bytes into file)
>> >   Size of section headers:           64 (bytes)
>> >   Number of section headers:         14
>>
>> That's 896 bytes for the section table, starting at offset 1888.
>>
>> >   Section header string table index: 13
>>
>>
>> >
>> > Section Headers:
>> >   [13] .shstrtab         STRTAB           0000000000000000  000006e8
>> >        0000000000000078  0000000000000000           0     0     1
>>
>> 120 bytes of section headers strings, starting at offset 1768 (and not
>> allocatable -- no 'A' here).
>>
>> >
>> > Program Headers:
>> >   Type           Offset             VirtAddr           PhysAddr
>> >                  FileSiz            MemSiz              Flags  Align
>> >   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
>> >                  0x00000000000006e8 0x00000000000006e8  R E    10
>>
>> The loadable segment is 1768 bytes long, starting at the beginning of
>> the file (and therefore the beginning of the mapping).
>>
>> So you have a total of 1016 bytes of non-allocatable stuff at the end
>> that I've accounted for.  I assume that the whole file is 2784 bytes.
>
> Correct.
>
>> If you added text or data to bring PT_LOAD to between 3081 and 4095
>> bytes, then the section headers and/or section string table would
>> cross a page boundary.
>
> Ok, so that explains why things are working at the moment and it sounds like
> we have some wiggle room too. I'll look at moving the datapage anyway, since
> having these artificial limits is error-prone and fragile, but I don't think
> it's something we need to panic about immediately.
>
> Also, if you get to the bottom of your binutils issues with the section
> allocation, that might work for us since we don't really have any legacy
> binutils supporting arm64.

Just in case anyone still cares about this thread, moving the vvar
area back before the vdso text is queued up for 3.17.  I gave up on
reliably keeping binutils happy with my ugly hack.

--Andy