Thread (76 messages) flat view 76 messages, 8 authors, 2014-07-22
STALE4449d

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

From: luto@amacapital.net (Andy Lutomirski)
Date: 2014-07-22 00:14:35

On Wed, Jul 2, 2014 at 11:54 AM, Will Deacon [off-list ref] wrote:
Cheers for this, Andy.

On Wed, Jul 02, 2014 at 07:34:22PM +0100, Andy Lutomirski wrote:
quoted
On Wed, Jul 2, 2014 at 10:24 AM, Will Deacon [off-list ref] wrote:
quoted
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.
quoted
  Section header string table index: 13
quoted
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).
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help