rimage: manifest: Improve handling of empty segments

[softwarecki]

Fixed output segment size calculation. If a given output segment type did not contain any input section (was empty), its size was incorrectly calculated as 1 and then rounded to the page size (4096). This resulted in an unnecessary segment in a output file.

Improved handling of empty RODATA segment. If the RODATA segment does not contain any data, its type is now marked as empty. Cleared the readonly flag of RODATA segment because this segment also contains .data sections.

[lyakh]

Cleared the readonly flag of RODATA segment because this segment also contains .data sections.

We only have one section in the manifest, that contains both .data and .rodata, right? This is in fact not good, can this be fixed?

[softwarecki]

@lyakh

We only have one section in the manifest, that contains both .data and .rodata, right? This is in fact not good, can this be fixed?

I'm afraid there is no good solution for this. The manifest only supports max three segments. Currently we use them like this:

1. .text
2. .rodata .data
3. .bss
   I think this is due to the assumption that loadable modules don't have a .data section, only .text, .rodata and .bss.

[lyakh]

@lyakh

We only have one section in the manifest, that contains both .data and .rodata, right? This is in fact not good, can this be fixed?

I'm afraid there is no good solution for this. The manifest only supports max three segments. Currently we use them like this:

1. `.text`

2. `.rodata` `.data`

3. .`bss`
   I think this is due to the assumption that loadable modules don't have a `.data` section, only `.text`, `.rodata` and `.bss`.

I don't really understand this assumption - modules are allowed to have .rodata, i.e. const objects, e.g. operations, and they're allowed to have .bss, i.e. writable initialised to 0 data, why aren't they then supposed to have writable but initialised to non-0 values data?

[lgirdwood]

@lyakh

We only have one section in the manifest, that contains both .data and .rodata, right? This is in fact not good, can this be fixed?

I'm afraid there is no good solution for this. The manifest only supports max three segments. Currently we use them like this:

1. `.text`

2. `.rodata` `.data`

3. .`bss`
   I think this is due to the assumption that loadable modules don't have a `.data` section, only `.text`, `.rodata` and `.bss`.

I don't really understand this assumption - modules are allowed to have .rodata, i.e. const objects, e.g. operations, and they're allowed to have .bss, i.e. writable initialised to 0 data, why aren't they then supposed to have writable but initialised to non-0 values data?

I think we have been merging .rodata and .data in the same manifest section to date using the linker and rimage.

[keqiaozhang]

SOFCI TEST

[kv2019i]

Looks ok. @lyakh please take a look at the clarifications.

questions remain, but none of them are critical