Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved allocation of .bss(-like) sections #505

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

alchzh
Copy link
Collaborator

@alchzh alchzh commented Oct 24, 2024

The existing strategy for allocating .bss in RAM has a few problems

  • only one contiguous .bss region per FEM is supported.
  • alignment was not properly calculated for .bss, leading to linker errors

This commit generalizes our process for allocating .text, .data, .rodata, etc. to .bss and like as well. It also improves our support for different platforms by reducing the use of hardcoded section names for determining behavior in favor of attributes defined by the binary format like sh_type and sh_flags

With the new system, instead of passing unsafe_bss_segment to make_fem, .bss sections are allocated during the allocate_bom step. This is supported by free space regions that don't map to any data on the parent resource. The new code allows .bss regions to be allocated in existing RW regions that are mapped to data by zeroing out those areas.

Changes (incomplete):

  • Use SHT_NOBITS type to detect .bss(-like) sections on ELF toolchains

  • Create FreeSpaceWithoutData tag for allocating regions for .bss. These are created from MemoryRegion children of resources with data_range=None

  • Use SHF_ALLOC flag to determine whether section needs to be patched or not instead of hard coded list of names.

  • Pass flag to compiler to prevent .eh_frame generation

  • Backwards compatible with old bss allocation for now, emits deprecation warnings.

  • I have reviewed the OFRAK contributor guide and attest that this pull request is in accordance with it.

The existing strategy for allocating `.bss` in RAM has a few problems
 - only one contiguous `.bss` region per FEM is supported.
 - alignment was not properly calculated for `.bss`, leading to linker errors

This commit generalizes our process for allocating `.text`, `.data`,
`.rodata`, etc. to `.bss` and like as well. It also improves our support
for different platforms by reducing the use of hardcoded section names
for determining behavior in favor of attributes defined by the binary
format like `sh_type` and `sh_flags`

With the new system, instead of passing `unsafe_bss_segment` to
`make_fem`, `.bss` sections are allocated during the `allocate_bom`
step. This is supported by free space regions that don't map to any
data on the parent resource.

Changes (incomplete):
- Use SHT_NOBITS type to detect .bss(-like) sections on ELF toolchains
- Create `FreeSpaceWithoutData`` tag for allocating regions for .bss.
  These are created from `MemoryRegion` children of resources with
  `data_range=None`
- Use SHF_ALLOC flag to determine whether section needs to be patched
  or not instead of hard coded list of names.
- Pass flag to compiler to prevent `.eh_frame` generation
- Backwards compatible with old bss allocation for now, emits
  deprecation warnings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants