Skip to content

Split data, bss, noinit sections into application and kernel areas #3622

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

Closed
zephyrbot opened this issue May 24, 2017 · 6 comments
Closed

Split data, bss, noinit sections into application and kernel areas #3622

zephyrbot opened this issue May 24, 2017 · 6 comments
Assignees
Labels
area: Kernel Enhancement Changes/Updates/Additions to existing features priority: high High impact/importance bug
Milestone

Comments

@zephyrbot
Copy link
Collaborator

zephyrbot commented May 24, 2017

Reported by Andrew Boie:

We need to split global data areas into application and kernel areas. If memory protection is enabled, all toplevel data, noinit, and bss declarations that are not part of the application should be in a memory region that is completely inaccessible to non-supervisor threads. Devise a way to do this in the linker scripts.

(Imported from Jira ZEP-2184)

@zephyrbot
Copy link
Collaborator Author

by Andrew Boie:

This should not be too bad. In the linker script you can do section routing on source file basis. Example:

130
131         SECTION_DATA_PROLOGUE(kernel_data, (OPTIONAL),)
132         {
133                 kernel/lib.a *(".data.*")
134         }
135
136         SECTION_DATA_PROLOGUE(_DATA_SECTION_NAME, (OPTIONAL),)

Currently, the main linker script takes in the following files:

-nostartfiles -nodefaultlibs -nostdlib -static -Wl,-X -Wl,-N -Wl,--gc-sections -Wl,--build-id=none
-Wl,-Map=zephyr.map
-L ./include/generated
-u _OffsetAbsSyms -u _ConfigAbsSyms
-e __start
-Wl,--start-group
-Wl,--whole-archive

 src/built-in.o
libzephyr.a
-Wl,--no-whole-archive
kernel/lib.a
./arch/x86/core/offsets/offsets.o
-Wl,--end-group
 -L /opt/zephyr-sdk/sysroots/i586-zephyr-elf/usr/lib/i586-zephyr-elf/6.2.0 -L /opt/zephyr-sdk/sysroots/i586-zephyr-elf/usr/lib/.  -lgcc

This will need to be rearranged a little bit.

  1. A .a file representing the core kernel, arch/ code, subsys/, drivers/. The "core kernel" which userspace cannot touch.
  2. A .a file representing the application. Application source, plus whatever library code we think can live in userspace.

Will need to decide on a case-by-case basis what under ext/ and lib/ should go in user/kernel space.

At the moment, we are not trying to split out program text or rodata, program text and rodata will remain a unified blob. We may reconsider this later.

@zephyrbot
Copy link
Collaborator Author

by Andrew Boie:

Hi All,

Here is a work-in-progress patch series to split out kernel/application data.
It's not ready to submit for a PR, I still have some more work/cleanup to do. But it's more than enough to discuss tomorrow I think.

https://github.com/andrewboie/zephyr/tree/linkage-wip

Example objdump output:

outdir/qemu_x86/zephyr.elf:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 text          00002bc4  00100000  00100000  00000080  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 devconfig     00000060  00102bc4  00102bc4  00002c44  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 rodata        000013f4  00102c24  00102c24  00002ca4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 app_datas     00000004  00104018  00104018  00004098  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 app_bss       000005e0  00104020  00104020  0000409c  2**5
                  ALLOC
  5 app_noinit    00000400  00104600  00104600  0000409c  2**5
                  ALLOC
  6 datas         0000002c  00104a00  00104a00  000040a0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 initlevel     00000060  00104a2c  00104a2c  000040cc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 bss           00000310  00104aa0  00104aa0  0000412c  2**5
                  ALLOC
  9 noinit        00001f00  00104db0  00104db0  0000412c  2**2
                  ALLOC
 10 .comment      00000011  00000000  00000000  0000412c  2**0
                  CONTENTS, READONLY
 11 .debug_aranges 00000b20  00000000  00000000  00004140  2**3
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_info   0001415f  00000000  00000000  00004c60  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_abbrev 00005600  00000000  00000000  00018dbf  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_line   000062fd  00000000  00000000  0001e3bf  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_frame  0000250c  00000000  00000000  000246bc  2**2
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_str    00003604  00000000  00000000  00026bc8  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_loc    000063cb  00000000  00000000  0002a1cc  2**0
                  CONTENTS, READONLY, DEBUGGING
 18 .debug_ranges 00000e78  00000000  00000000  00030598  2**3
                  CONTENTS, READONLY, DEBUGGING

Regards,
Andrew

@zephyrbot
Copy link
Collaborator Author

by Adithya Baglody:

Andrew quick question-
why cant we do something like this for the kernel data segregation ?

{code:c}
int i attribute((section ("kernel_data"))) = 0;
{code}

@zephyrbot
Copy link
Collaborator Author

by Andrew Boie:

Adithya Baglody I don't want to have to go through the entire kernel tree and manually set the section on every single global.

@zephyrbot
Copy link
Collaborator Author

by Andrew Boie:

#546

@zephyrbot
Copy link
Collaborator Author

zephyrbot commented Jun 19, 2017

Blocks GH-3630

@zephyrbot zephyrbot added priority: high High impact/importance bug area: Kernel Enhancement Changes/Updates/Additions to existing features labels Sep 23, 2017
@zephyrbot zephyrbot added this to the v1.9.0 milestone Sep 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Kernel Enhancement Changes/Updates/Additions to existing features priority: high High impact/importance bug
Projects
None yet
Development

No branches or pull requests

2 participants