.sdata2/.sbss2 section generated by toolchain

[Chang, Abner (HPS SW/FW Technologist)]

Hi all,

Recently we encounter an build issue,  that is edk2 RISC-V binary which built from the latest RISC-V toolchain has problem to boot system. The root cause was found by Mark from Redhat,  which is the CONSTs are put into .sdata2 section, this ends up the relocation could not be fixed up correctly using edk2 build tool. Is there any link option can force CONST to not staying with special section or can we force CONSTs to be in .text section?

 

Thanks

Abner

[Jim Wilson]

On Wed, Nov 20, 2019 at 7:59 AM Chang, Abner (HPS SW/FW Technologist)
<abner...@hpe.com> wrote:
> Recently we encounter an build issue, that is edk2 RISC-V binary which built from the latest RISC-V toolchain has problem to boot system. The root cause was found by Mark from Redhat, which is the CONSTs are put into .sdata2 section, this ends up the relocation could not be fixed up correctly using edk2 build tool. Is there any link option can force CONST to not staying with special section or can we force CONSTs to be in .text section?

I don't know what edk2 is, or why relocs for the .sdata2 sections
would be a problem.

As far as I know, the riscv toolchain does not use sdata2 sections.
It does use srodata sections which are similar, but are placed next to
the small data sections, unlike sdata2 which is placed near the
read-only sections. Though checking the gcc sources, I managed to
figure out that there is a bug, where -fdata-sections causes variables
to end up in .sdata2.* sections instead of .srodata.* sections. It
also looks like this can happen for C++ comdat variables. Maybe
fixing this solves your problem. It appears that we need to define a
TARGET_ASM_UNIQUE_SECTION hook in the riscv backend that works like
the existing riscv_select_section hook.

Meanwhile, the compiler places stuff in srodata (and accidentally
sdata2) if it is small and read-only. So to avoid that, it either
needs to be non-small or non-read-only. You can disable the small
data optimization by using -G 0. You can disable the read-only
optimization by defining away const.

If you are OK with changing compiler sources, you can disable the
TARGET_HAVE_SRODATA_SECTION hook in the gcc/config/riscv/riscv.h file
and rebuild.

At the linker level, assuming that all uses of sdata2 are mistaken
references to srodata, and assuming that srodata is actually OK, then
you can edit the linker script to place sdata2 sections next so
srodata sections. if you already have a linker script you can just
edit that. If you don't already have a linker script, then you can
get the linker script by adding -v to the linker options (-Wl,-v if
using gcc to link), then cut and paste everything between the two long
lines with equal signs on them into a linker script file, move the
sdata2 section to where srodata is, and then link using this linker
script (-T followed by the file name if using gcc to link).

Jim

[Chang, Abner (HPS SW/FW Technologist)]

Jim, thanks for the detail information. This helps lot since I am not quite familiar with gnu toolchain.
We found there is an option for RISC-V to limit the small data be placed in .sdata2 section. With the option -msmall-data-limit set to 0, the small data will be put into .text. -G seems doesn't work on RISC-V arch though.
With this option we don’t have to modify the common lds provided by edk2 build environment. Thanks!

BTW, edk2 is an open source which is the implementation of UEFI spec. I have been working on UEFI RISC-V edk2 port to bring up RISC-V edk2 on SiFive platforms.
Abner

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sw-dev+un...@groups.riscv.org.
> To view this discussion on the web visit
> INVALID URI REMOVED
> 3A__groups.google.com_a_groups.riscv.org_d_msgid_sw-
> 2Ddev_CAFyWVaZfkZW-252BhYsD-
> 253DYBZXxTevZUWd6OVoCTVcaekcKCCrKK7-2DQ-
> 2540mail.gmail.com&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZ
> BN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=6AQZattc_EEd9WT0kDZYgl
> aYINrpAalSLs0UUlxNbMw&s=1CZjgLxN_rVpqNPGPrMqAO-
> ikg3mk75nF48tLfAzrIQ&e= .

[Tommy Murphy]

Apologies for bumping this old thread and piggybacking on it but I thought it better do post here rather than create a new thread.

Is there any way to know what sections the RISC-V toolchain (in particular the newlib/bare metal toolchain but ideally also the Linux toolchain) can ever generate or is that more of a target neutral question?

I can't seem to find any authoritative source of information about this and have seen some or all of the following mentioned in various places...

.text
.data
.sdata
.sdata2
.rodata
.rodata2 ?
.bss
.sbss
.sbss2
.heap
.stack
.init
.fini
.ctors
.dtors
.eh_frame
.got
.got2

[Maciej W. Rozycki]

On Wed, 22 Apr 2020, Tommy Murphy wrote:

> Is there any way to know what sections the RISC-V toolchain (in particular
> the newlib/bare metal toolchain but ideally also the Linux toolchain) can
> ever generate or is that more of a target neutral question?

Sections of certain standard names have a predefined purpose and are
implicitly produced by the compiler, assembler or the static linker.

For example the ELF gABI defines its section names here:
<http://www.sco.com/developers/gabi/latest/ch4.sheader.html#special_sections>.
Further standard section names may be defined by individual architectures'
psABI documents, other standards such as the DWARF Debugging Information
Format specification, or used by toolchain implementations or associated
tools (such as the prelinker) as a need arises.

Otherwise section names have no preassigned meaning and arbitrary names
can be requested by software writers and therefore appear in output,
according to the syntax of the programming language used (e.g. the GNU
assembler has `.section' and a couple of other pseudo-ops for that
purpose).

What problem are you trying to solve? Depending on that different
answers may be the right one.

Maciej

[Georg Nikodym]

Short answer is no. There is no way to accurately predict what sections will be in an ELF file, or how they will be named.

Pretty easy to see what sections _are_ in an ELF file (readelf -S being one way).

And yes, sort of a target neutral question (I say sort of because a platforms do have conventions about section names).

However, toolchains are free to make as many arbitrary sections as they like (that’s the E part of ELF).

Some ways in which devs (ab)use sections:

 - gcc’s -ffunction-sections and -fdata-sections options will put each symbol into it’s own section

 - gcc __attributes__ — developers can direct symbols to specific sections

 - linker scripts can be used to control sections and their content

Of course, your question doesn’t illuminate the real problem you’re trying to solve...

-g 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/e90446cb-24f8-4be2-9cfe-b9fa74d2db74%40groups.riscv.org.

[Tommy Murphy]

Thank you for the reply Maciej.

So I guess that RISC-V section usage should be explained here ideally?

https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

I'm not trying to solve any problem other than to understand in what circumstances different sections are generated by the RISC-V gcc toolchain.

For example in some circumstances I have seen .sdata2 generated but not in others and I have no idea why (gcc 8.3 but not in earlier versions with the same project/code).

I'm particularly confused about the appearance of .sdata2 when Jim seems to suggest above that it should not be generated for RISC-V (and my code is C not C++ in this case).

Maybe that is something that is addressed in a later gcc for RISC-V? gcc 9.x?

Thanks again for the input

Regards

Tommy

[Tommy Murphy]

On Wednesday, 22 April 2020 14:41:12 UTC+1, Georg Nikodym wrote:

Of course, your question doesn’t illuminate the real problem you’re trying to solve...

Thanks Georg - I think my previous post in reply to Maciej clarifies?

Just to expand I want to provide example linker scripts that will always work for our embedded RISC-V targets but in the absence of information about the "standard" sections that may be emitted by the tools it's difficult to do this.

I understand that section names such as .text etc. are simply conventional but they are arguably standard in practice?

And I also understand that users can add or use arbitrary sections but I am more concerned here with the "standard" sections that the tools can generate - i.e. some or all of the list that I mentioned above and maybe also others?

Thanks a lot

Regards

Tommy

[Georg Nikodym]

Yes. Sorry, replies crossing in the night.

In my experience (admittedly “anecdotal”, as in I can’t point at a reference), yes, section names are standard-ish in practice.

In the context of linker scripts, it is common to use wildcards to catch permutations of “standard” names. This example from an ARM based project I’m working on:

  /* Constant data goes into FLASH */

  .rodata :

  {

    . = ALIGN(4);

    *(.rodata)         /* .rodata sections (constants, strings, etc.) */

    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */

    . = ALIGN(4);

  } >FLASH

This particular project’s build uses -ffunction-sections and -fdata-sections, so gcc creates section names with a predictable prefix (like .rodata.symbol) in each generated .o. The wildcarding in the linker script catches all these names and creates a single .rodata section in the final executable.

Not sure if that’s helpful.

-g

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/d637ffd3-8928-4677-a554-76fb6c063034%40groups.riscv.org.

[Tommy Murphy]

Thanks Georg.

My specific confusion arose here because with gcc 8.3 we have a project that generates .sdata2._global_impure_ptr but the same project (same tool settings etc.) with an older version does not.

I need to double check what happens with the older tools as I can't recall offhand unfortunately... :-|

I am aware of the general approach to wildcards and section names but unfortunately that doesn't help with the key question of what the "standard" (?) section names are that can be generated by the RISC-V tools.

[Tommy Murphy]

This is the example to which I was referring - exactly the same project and tool settings in each case.

Note the .sdata2._global_impure_ptr in the first case.

gcc 8.3

Invoking: GNU RISC-V Cross Print Size

riscv64-unknown-elf-size --format=sysv --radix=16 "UC_20.elf"

UC_20.elf  :

section                          size        addr

.text                          0xa560   0x8000000

.ram_code                        0x68   0x1001c00

.sdata2._global_impure_ptr        0x8   0x1001c68

.sdata                           0x60   0x800a5d0

.data                           0xf60   0x800a630

.sbss                            0x50   0x800b590

.bss                            0x550   0x800b5e0

.heap                          0x1000   0x800bb30

.stack                         0x1400   0x800d000

.debug_info                  0x21ef27         0x0

.debug_abbrev                  0x44bf         0x0

.debug_aranges                 0x28b0         0x0

.debug_ranges                  0x27a0         0x0

.debug_macro                   0xe527         0x0

.debug_line                   0x1c9f9         0x0

.debug_str                    0x4f995         0x0

.comment                         0x51         0x0

.riscv.attributes                0x35         0x0

.debug_frame                   0x7dc0         0x0

Total                        0x2b8a61

gcc 7.2

Invoking: GNU RISC-V Cross Print Size
riscv64-unknown-elf-size --format=sysv --radix=16 "UC_20.elf"
UC_20.elf  :
section              size        addr
.text              0xa730   0x8000000
.ram_code            0x68   0x1001c00
.sdata               0x70   0x800a7a0
.data               0xf60   0x800a810
.sbss                0x50   0x800b770
.bss                0x550   0x800b7c0
.heap              0x1000   0x800bd10
.stack             0x1400   0x800d000
.debug_info      0x1fad32         0x0
.debug_abbrev      0x3ebb         0x0
.debug_aranges     0x28b0         0x0
.debug_ranges      0x27a0         0x0
.debug_macro       0xe482         0x0
.debug_line       0x16586         0x0
.debug_str        0x4f86b         0x0
.comment             0x58         0x0
.debug_frame       0x6d40         0x0
Total            0x28cd50

[Georg Nikodym]

Educated(?!?) guess is that you’re getting this new section not from the compiler per se but rather from the libc/newlib/whatever is packaged inside your tool chain _and_ that the section weirdness is from something like `__attribute__ ((__section__(.sdata2)))` buried somewhere in that code.

-g

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/ac3e17b9-a589-44c0-80eb-4dee94cc386a%40groups.riscv.org.

[Tommy Murphy]

Good point Gerog.

I had, at one stage, wondered if it was maybe due to newlib/newlib-nano but then forgot to chase that up.

I will do so and post back if/when I find anything useful.

Thanks again.

[Jim Wilson]

On Wed, Apr 22, 2020 at 6:43 AM Tommy Murphy <tommy_...@hotmail.com> wrote:
> For example in some circumstances I have seen .sdata2 generated but not in others and I have no idea why (gcc 8.3 but not in earlier versions with the same project/code).
> I'm particularly confused about the appearance of .sdata2 when Jim seems to suggest above that it should not be generated for RISC-V (and my code is C not C++ in this case).
> Maybe that is something that is addressed in a later gcc for RISC-V? gcc 9.x?

Yes, that is a bug in the RISC-V gcc port. We need to define
TARGET_ASM_UNIQUE_SECTION to do the right thing for RISC-V. No it
isn't fixed yet. There are far more problems to fix than I can fix by
myself. I started on a patch once but never had a chance to finish
it.

Jim

[Tommy Murphy]

On Thursday, 23 April 2020 18:41:23 UTC+1, Jim Wilson wrote:

Yes, that is a bug in the RISC-V gcc port.  We need to define
TARGET_ASM_UNIQUE_SECTION to do the right thing for RISC-V.  No it
isn't fixed yet.  There are far more problems to fix than I can fix by
myself.  I started on a patch once but never had a chance to finish
it.

Jim

Thanks Jim. No worries. I was just trying to understand the common/conventional sections.

I understand that there are probably bigger fish to fry in terms of tools issues.

Cheers

Tommy

[Chang, Abner (HPS SW/FW Technologist)]

My experience maybe not helpful on this matter, but what I would like to share is .sdata2 section wasn’t existing once I set –msall-data-limit=0 to not allowing section for the small data.

Yes, this is not happened in earlier version of gcc.

 

From: Tommy Murphy [mailto:tommy_...@hotmail.com]
Sent: Friday, April 24, 2020 3:59 AM
To: RISC-V SW Dev <sw-...@groups.riscv.org>
Cc: tommy_...@hotmail.com; Chang, Abner (HPS SW/FW Technologist) <abner...@hpe.com>; ma...@wdc.com
Subject: Re: [sw-dev] .sdata2/.sbss2 section generated by toolchain

 

On Thursday, 23 April 2020 18:41:23 UTC+1, Jim Wilson wrote:

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/6c587f0d-ba94-4eef-b097-d44bda69d4bd%40groups.riscv.org.

[Tommy Murphy]

On Friday, 24 April 2020 02:01:58 UTC+1, Chang, Abner (HPS SW/FW Technologist) wrote:

My experience maybe not helpful on this matter, but what I would like to share is .sdata2 section wasn’t existing once I set –msall-data-limit=0 to not allowing section for the small data.

Yes, this is not happened in earlier version of gcc.

Thanks for your input.

Appreciate it.  

[Keith Packard]

Here's a patch, cribbed from other places which override
TARGET_ASM_UNIQUE_SECTION

[Jim Wilson]

On Wed, Apr 29, 2020 at 9:57 AM Keith Packard <keith....@sifive.com> wrote:
> Here's a patch, cribbed from other places which override
> TARGET_ASM_UNIQUE_SECTION

The patch looks correct. I committed it to the FSF GCC tree. We
should probably backport it to the riscv-gnu-toolchain tree also. And
maybe backport to the gcc-10 branch too.

Jim