Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #2344
Closed
Open
Issue created Apr 10, 2017 by Administrator@rootContributor

module_read_os_data() might not work

Created by: egrimley

It looks for the program headers at base + elf_hdr->e_phoff, but e_phoff is the "program header table file offset", which is not in general the same as the offset in memory. I don't think it's possible to find the program headers from a pointer to the ELF file header in memory so the API of this function should be changed.

I noticed this because about 20 tests failed on an AArch64 system where the output from readelf -l .../libstdc++.so.6 looked like this:

...
There are 8 program headers, starting at offset 12451840

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x000000000018323b 0x000000000018323b  R E    0x10000
...
  LOAD           0x0000000000be0000 0x00000000001b0000 0x00000000001b0000
                 0x00000000000417a8 0x00000000000417a8  RW     0x10000
...

So the program headers are in that last loadable segment, which has file offset 0xbe0000 (= 12451840), but an offset in memory of 0x1b0000.

Unfortunately I'm not sure exactly where this libstdc++.so.6 came from so I can't say how likely it is that this problem will affect other people.

Usually the program headers are in the same loadable segment as the ELF header, but I'm not sure that the ELF standards require the program headers to be loaded at all. If DynamoRIO is assuming something that is not required by the ELF standards then it would be good to document those assumptions.

Assignee
Assign to
Time tracking