Adding pointers to a custom ELF section

[agamez]

Hi!

I'm building a modular system that will communicate through RS232 and will impersonate different interfaces (binary, interactive/human, proprietary ascii commands such as those used in motor controller devices, etc). The idea is to have a small FPGA running neorv32 that can simulate different hardware devices, such as the motor controller I mentioned, but can also switch to an interactive human mode to inspect registers and the like.

To keep the system modular I want to use the custom ELF section strategy and so I have the following code:

struct personality {
        char name[32];
        int (*art_reg_if)(struct art_reg_if_cb *cb);
};

#define REGISTER_PERSONALITY(p) \
        static struct personality *_personality_##p                     \
                __attribute((__section__("personalities")))             \
                __attribute((__used__)) = (struct personality *)&p

const struct personality personality_machine = {
        .name = "MACHINE",
        .art_reg_if = machine_art_reg_if,
};

REGISTER_PERSONALITY(personality_machine);

const struct personality personality_human = {
        .name = "HUMAN",
        .art_reg_if = human_art_reg_if,
};

REGISTER_PERSONALITY(personality_human);

static struct personality *get_personality(char *personality)
{
        extern struct personality *__start_personalities;
        extern struct personality *__stop_personalities;

        extern struct personality personality_human;
        extern struct personality personality_machine;
        neorv32_uart0_printf("HUMAN: %p\n", &personality_human);
        neorv32_uart0_printf("MACHINE: %p\n\n", &personality_machine);

        neorv32_uart0_printf("START: %p\n", &__start_personalities);
        struct personality **p;
        for (p = &__start_personalities; p < &__stop_personalities; p++) {
                neorv32_uart0_printf("Testing %p against '%s'\n", *p, personality);
//              if (!strcmp((*p)->name, personality))
//                      return (*p);
        }
        neorv32_uart0_printf("STOP: %p\n", &__stop_personalities);
        while(1);
        return NULL;
}

I saw that common.mk removes all sections beyond .text, .rodata and .data, so I just modified it to include custom personalities section:

--- a/sw/common/common.mk
+++ b/sw/common/common.mk
@@ -206,8 +206,8 @@ main.bin: $(APP_ELF)
    @$(OBJCOPY) -I elf32-little $< -j .text   -O binary text.bin
    @$(OBJCOPY) -I elf32-little $< -j .rodata -O binary rodata.bin
    @$(OBJCOPY) -I elf32-little $< -j .data   -O binary data.bin
-   @cat text.bin rodata.bin data.bin > $@
-   @rm -f text.bin rodata.bin data.bin
+   @$(OBJCOPY) -I elf32-little $< -j personalities   -O binary personalities.bin
+   cat text.bin rodata.bin data.bin personalities.bin > $@

I keep the .bin files so I can inspect personalities.bin:

$ hexdump -Cv personalities.bin 
00000000  2c 2b 00 00 d0 2b 00 00                           |,+...+..|

This matches with the contents of make elf_info output:

$ grep personality elf_info
80000694 l     O personalities	00000004 _personality_personality_machine
80000698 l     O personalities	00000004 _personality_personality_human
00002bd0 g     O .rodata	00000024 personality_human
00002b2c g     O .rodata	00000024 personality_machine

So it looks like there exists struct personality *_personality_personality_machine poiting to personality_human and struct personality *_personality_personality_human pointing to personality_human which is exactly what the REGISTER_PERSONALITY macro was supposed to do.

Now, here lies the problem. I created a couple of #defines to replace neorv32_uart0_printf with simply printf so I can run the exact same code compiled for linux on my PC instead of as a standalone executable, and the code above runs like this on my computer:

$ ./a.out
HUMAN: 0x564f028a6c60
MACHINE: 0x564f028a6ca0

START: 0x564f028a7078
Testing 0x564f028a6c60 against 'MACHINE'
Testing 0x564f028a6ca0 against 'MACHINE'
STOP: 0x564f028a7088

If I allow the commented out strcmp line to work, it will find the proper pointer to personality_machine. However, when I run this exact same code on neorv32, this is what I see:

HUMAN: 00002bd0
MACHINE: 00002b2c

START: 80000694
Testing 00000000 against 'MACHINE'
Testing 00001220 against 'MACHINE'
STOP: 8000069c

So, for some reason, even of START and STOP pointers do match with the start of _personality_personality_machine and end of _personality_personality_machine and personalities.bin seem to properly point to 0x00002bd0 and 0x00002b2c, when the code is run, it doesn't match at all, so trying to access the .name struct member to execute the strcmp function, it fails with Load access faults or simply doesn't really find the string it's supposed to.

I have no doubt this is all due to my tinkering with the object file, but I don't know the reason, because elf_info shows that the personalities section is indeed placed after the ones it already had, so I believe it should've worked:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000027d8  00000000  00000000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000007e8  000027d8  000027d8  000037d8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000694  80000000  00002fc0  00004000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 personalities 00000008  80000694  00003654  00004694  2**2
                  CONTENTS, ALLOC, LOAD, DATA

So this has been the end of my investigation, as I don't know what else should I check/modify to get this working. I'd appreciate any help.

Thanks!

[stnolting]

Hey @agamez.

Ok, this is a challenging setup as I am no software/C expert at all... 😅

Did you also modify the linker script (adding your new section there)? If not then cropping out the personalities section and concatenating it with the .text, .rodata and .data sections might cause an address inconsistency.

Why do you need a special section for your data? You could also use a "sub-section" of a default section like .bss.personalities.

However, I made some simple tests with a custom section that is not defined in the linker script. It works - surprisingly.

#include <neorv32.h>

extern char __crt0_bss_start[];
extern char __crt0_bss_end[];
extern char __crt0_copy_data_dst_begin[];
extern char __crt0_copy_data_dst_end[];

volatile uint32_t var_bss __attribute__((__section__(".bss")));
volatile uint32_t var_data __attribute__((__section__(".data")));
volatile uint32_t var_cust __attribute__((__section__(".custom")));

int main() {

  neorv32_rte_setup();
  neorv32_uart0_setup(19200, 0);
  
  neorv32_uart0_printf("\n#725\n\n");

  neorv32_uart0_printf("DATA start = 0x%x\n", (uint32_t)__crt0_copy_data_dst_begin);
  neorv32_uart0_printf("DATA end   = 0x%x\n", (uint32_t)__crt0_copy_data_dst_end);
  neorv32_uart0_printf("BSS start  = 0x%x\n", (uint32_t)__crt0_bss_start);
  neorv32_uart0_printf("BSS end    = 0x%x\n\n", (uint32_t)__crt0_bss_end);

  var_bss = 0xaabbccdd;
  neorv32_uart0_printf("&var_bss  = 0x%x\n", &var_bss);
  neorv32_uart0_printf(" var_bss  = 0x%x\n\n", var_bss);

  var_data = 0x12345678;
  neorv32_uart0_printf("&var_data = 0x%x\n", &var_data);
  neorv32_uart0_printf(" var_data = 0x%x\n\n", var_data);

  var_cust = 0xffffffff;
  neorv32_uart0_printf("&var_cust = 0x%x\n", &var_cust);
  neorv32_uart0_printf(" var_cust = 0x%x\n\n", var_cust);

  neorv32_uart_printf(NEORV32_UART0, "Program completed.\n");
  return 0;
}

var_bss and var_data get mapped to the default .bss and .data sections, but for var_cust I am defining a new section called .custom. Since this section is not defined in the linker script and I am just using the default setup without I was expecting this might cause a problem when mapping to physical address.

$ make USER_FLAGS+=-DUART0_SIM_MODE clean_all sim
#725

DATA start = 0x80000000
DATA end   = 0x80000004
BSS start  = 0x80000008
BSS end    = 0x80000080

&var_bss  = 0x80000008
 var_bss  = 0xaabbccdd

&var_data = 0x80000000
 var_data = 0x12345678

&var_cust = 0x80000004
 var_cust = 0xffffffff

Program completed.

As you can see from the program output the new section survived linking and was mapped right between .data and .bss:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000ed8  00000000  00000000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000003ac  00000ed8  00000ed8  00001ed8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000004  80000000  00001284  00003000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .custom       00000004  80000004  00001288  00003004  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000078  80000008  0000128c  00003008  2**2
                  ALLOC
  5 .heap         00000000  80000080  80000080  00003008  2**2
                  CONTENTS

80000000 g     O .data	  00000004 var_data
80000008 g     O .bss	  00000004 var_bss
80000004 g     O .custom  00000004 var_cust

However, this will not work for pre-initialized variables being mapped to .custom as the initialization code for those variable takes care of the .data section only.

[agamez]

Hi @stnolting !

Ok, this is a challenging setup as I am no software/C expert at all... 😅

Well, neither do I, I guess. At least I've never needed to tinker with object sections before, because this way has always worked for me.

Did you also modify the linker script (adding your new section there)? If not then cropping out the personalities section and concatenating it with the .text, .rodata and .data sections might cause an address inconsistency.

Well, I did not and it didn't even occur to me. But I don't believe it to be necessary because the original ELF file already had my custom section right after .data, so concatenating it means that I simply append it where it originally was.

Why do you need a special section for your data? You could also use a "sub-section" of a default section like .bss.personalities.

I... don't know? 😅 I've always used the full custom section way, as that's the typical usage of this "trick". How would you reference the start/end of this sub-section?

I'll keep looking and testing and will let you know...

Thanks!

[stnolting]

Adding a completely new sections seems to work (see the example code I have posted) - but to be honest, I am not quite sure why those sections are mapped where they are being mapped...

The cleanest and most backwards-compatible way would be to add a new section to the linker script while also providing (externalized) linker variables for this. Here is an example for a custom section ".custom" inside the .bss section (put it into an already existing section so you do not need to objdump/concatenate things):

/* custom bss sub-section */
. = ALIGN(4);
PROVIDE (.bss.custom_begin = .);
*(.custom*)
PROVIDE (.bss.custom_end = .);

The two symbols .bss_custom_* can be used by your C program to determine beginning and end of your custom section.