Add loading of ET_DYN shared object test to sotest #2026

nealef · 2023-09-04T01:04:23Z

examples/sotest/lib/Makefile
- Add dynload directory to build
examples/sotest/lib/dynload/Makefile
- Build the dynload shared object test
examples/sotest/lib/dynload/dynload.c
- Test case for loading of ET_DYN shared objects
examples/sotest/lib/dynload/.gitignore
- Exclude built object from git
examples/sotest/sotest_main.c
- Load and invoke the dynload test

Summary

Support of ET_DYN shared objects was added to NuttX, this PR adds a test.

Impact

New test dynload is built.

Testing

Run sotest and the dynload shared object will be loaded, a symbol located and invoked, and the module unloaded.

examples/sotest/lib/dynload/dynload.c

xiaoxiang781216 · 2023-09-07T07:54:27Z

@nealef please fix the ci warning, you can run the check locally by:

../nuttx/tools/checkpatch.sh -g HEAD~2...HEAD

pkarashchenko · 2023-09-07T08:26:09Z

We need to fix CI build first

pkarashchenko · 2023-09-08T12:41:59Z

ld: i386 architecture of input file 'dynload.o' is incompatible with i386:x86-64 output

nealef · 2023-09-12T05:06:01Z

ld: i386 architecture of input file 'dynload.o' is incompatible with i386:x86-64 output

Where was this error? I build dynload.o like modprint.o: i.e. using $(MODULECC) so I am not sure why it would generate the incorrect output.

pkarashchenko · 2023-09-12T05:07:35Z

ld: i386 architecture of input file 'dynload.o' is incompatible with i386:x86-64 output

Where was this error? I build dynload.o like modprint.o: i.e. using $(MODULECC) so I am not sure why it would generate the incorrect output.

I copied that error message from CI failure log

nealef · 2023-09-12T06:09:00Z

What I've found is when modprint is built we get this command line:

ld -r -e module_initialize --gc-sections -T /home/neale/nuttx/libs/libc/modlib/gnu-elf.ld -melf_i386  -o modprint  modprint.o

But for dynload we get:

ld -Bsymbolic -G -Bdynamic --no-gc-sections  -L /home/neale/nuttx/staging -o dynload dynload.o -lc

This is due to the settings of various flags in boards/sim/sim/sim/scripts/Make.defs. I'll add some for shared object linking and make corresponding changes in nuttx-apps/examples/sotest/lib/dynload/Makefile.

nealef · 2023-09-12T06:13:17Z

Made the changes and get a clean build but when I build and run sim:sotest32 on my x64 Ubuntu 20.04 system I crash with:

NuttShell (NSH)
nsh> sotest
main: Registering romdisk at /dev/ram3
main: Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram3
module_initialize:
Process 3421077 stopped
* thread #1, name = 'nuttx', stop reason = signal SIGILL: illegal instruction operand
    frame #0: 0xf3df4651
->  0xf3df4651: lock
    0xf3df4652: fpatan

So I am wondering if I need to run it on something else? My Mac isn't an option either as there's no support for 32-bit.

examples/sotest/lib/dynload/dynload.c

xiaoxiang781216 · 2023-09-21T03:31:43Z

@nealef please fix the build error reported by ci.

nealef · 2023-09-21T05:02:56Z

That was supposed to be fixed by an earlier commit that changed SHLDMODULEFLAGS to SHMODULEDLAGS. It was clean yesterday where the only failure was to do with libcxxtest or a similar name.

…

-------- Original message -------- From: Xiang Xiao ***@***.***> Date: 21/9/23 13:32 (GMT+10:00) To: apache/nuttx-apps ***@***.***> Cc: Neale Ferguson ***@***.***>, Mention ***@***.***> Subject: Re: [apache/nuttx-apps] Add loading of ET_DYN shared object test to sotest (PR #2026) @nealef<https://github.com/nealef> please fix the build error reported by ci. — Reply to this email directly, view it on GitHub<#2026 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACLN6QGBQ2G56Q7LO442N3X3OYKXANCNFSM6AAAAAA4JVY5HA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

nealef · 2023-09-21T05:24:58Z

That was a fix to nuttx-apps under commit bb32dd2. #2026

xiaoxiang781216 · 2023-09-21T05:48:45Z

But the link error is directly related to this patch:

====================================================================================
Configuration/Tool: sim/sotest32
------------------------------------------------------------------------------------
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
  Cleaning...
  Configuring...
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
  Building NuttX...
ld: i386 architecture of input file `dynload.o' is incompatible with i386:x86-64 output
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
make[4]: *** [Makefile:45: dynload] Error 1
make[4]: Target 'install' not remade because of errors.
make[3]: *** [Makefile:50: dynload_install] Error 2
make[3]: Target 'all' not remade because of errors.
make[2]: *** [Makefile:53: build] Error 2
make[2]: Target 'all' not remade because of errors.
make[1]: *** [Makefile:51: /github/workspace/sources/apps/examples/sotest_all] Error 2
make[1]: Target 'all' not remade because of errors.
make: *** [tools/LibTargets.mk:232: /github/workspace/sources/apps/libapps.a] Error 2
make: Target 'all' not remade because of errors.

nealef · 2023-09-21T06:02:18Z

How can I tell what's in the nuttx-apps it's building against? In NuttX there is:

SHMODULEFLAGS = -Bsymbolic -G -Bdynamic
:
:
ifeq ($(CONFIG_SIM_M32),y)
  LDLINKFLAGS += -melf_i386
  LDFLAGS += -m32
  LDMODULEFLAGS += -melf_i386
  SHMODULEFLAGS += -melf_i386
  LDELFFLAGS += -melf_i386
endif

and in my branch of nuttx-apps is:

$(BIN): $(OBJS)
	@echo "MODULELD: $<"
	$(Q) $(MODULELD) $(SHMODULEFLAGS) $(LDLIBPATH) -o $@ $^ $(LDLIBS)

Which had solved the earlier problem of (1) the no _start symbol and (2) the mismatch between architectures. Is there a way of seeing the code this latest failure was built from to see if I've missed a commit or regressed something?

xiaoxiang781216 · 2023-09-22T01:19:51Z

you can reproduce the problem by
./tools/conffigure.sh sim/sotest32
make

nealef · 2023-09-22T03:37:56Z

I rebased my repo and it reported:

git status
On branch dynload-fix
Your branch is up to date with 'origin/dynload-fix'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	gpsutils/

nothing added to commit but untracked files present (use "git add" to track)

I then remade nuttx after configuring for sim:sotest32 and get:

/Users/neale/Wilderness/nuttx-build/apps/gpsutils/Kconfig:9: can't open file "/Users/neale/Wilderness/nuttx-build/apps/gpsutils/minmea/Kconfig"

xiaoxiang781216 · 2023-09-22T04:24:29Z

I rebased my repo and it reported:

git status
On branch dynload-fix
Your branch is up to date with 'origin/dynload-fix'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	gpsutils/

nothing added to commit but untracked files present (use "git add" to track)

I then remade nuttx after configuring for sim:sotest32 and get:

/Users/neale/Wilderness/nuttx-build/apps/gpsutils/Kconfig:9: can't open file "/Users/neale/Wilderness/nuttx-build/apps/gpsutils/minmea/Kconfig"

do you fetch both git(nuttx and apps) and rebase to the last master? A recent change move minmea from apps/gpsutils/ to nuttx/libc/minmea:
#1234
apache/nuttx#9954

nealef · 2023-09-22T06:38:14Z

Brought my master up to date:

IN: /Users/neale/Wilderness/nuttx-build/apps/libapps.a -> staging/libapps.a install: /Users/neale/Wilderness/nuttx-build/apps/libapps.a: No such file or directory

In any event it got past my dynload build:

MODULECC: sotest.c
MODULELD: sotest.o
MODULECC: modprint.c
MODULELD: modprint.o
MODULECC: dynload.c
MODULELD: dynload.o

nealef · 2023-09-26T00:56:57Z

Is the current libcxxtest failure something that a fetch/rebase will fix?

xiaoxiang781216 · 2023-09-26T02:00:10Z

Is the current libcxxtest failure something that a fetch/rebase will fix?

Yes, it fix by apache/nuttx#8244, let me retrigger the ci.

nealef · 2023-09-26T05:26:41Z

Latest failure is in risc-v with the _start error message indicating dynload is not being liked with the flags to build a shared object. Is there a way to get it to do a make V=1? I don't have access to any risc-v hardware to do it myself.

acassis · 2023-12-12T13:24:59Z

Also, as far as I can tell the following archs can support sotest (i.e. it's a selectable Kconfig option):
1. ./boards/xtensa/esp32/esp32-devkitc/configs/sotest/defconfig

2. ./boards/xtensa/esp32s2/esp32s2-saola-1/configs/sotest/defconfig

3. ./boards/risc-v/esp32c3/esp32c3-devkit/configs/sotest/defconfig

4. ./boards/risc-v/c906/smartl-c906/configs/sotest/defconfig

5. ./boards/sim/sim/sim/configs/sotest32/defconfig

6. ./boards/sim/sim/sim/configs/sotest/defconfig

7. ./boards/arm64/qemu/qemu-armv8a/configs/sotest/defconfig
Should I be specifying the SHMODULEFLAGS in the corresponding Make.defs file for each of those "boards" or in the arch generic files such as ./arch/risc-v/src/common/Toolchain.defs?

@xiaoxiang781216

@Donny9 @xiaoxiang781216 what do you think? Since SHMODULEFLAGS is defined to sim "board" I think it also will be needed for other arch's boards.

xiaoxiang781216 · 2023-12-12T16:58:16Z

Yes, or even better to move to Toolchain.defs, so it could be shared between boards

nealef · 2023-12-12T23:42:18Z

Yes, or even better to move to Toolchain.defs, so it could be shared between boards

sim doesn't have Toolchain.defs so I used: boards/sim/sim/sim/scripts/Make.defs. For RISC I was using arch/risc-v/src/common/Toolchain.defs and for armv8: boards/arm64/qemu/qemu-armv8a/scripts/Make.defs.

* examples/sotest/lib/Makefile - Add dynload directory to build * examples/sotest/lib/dynload/Makefile - Build the dynload shared object test - Use SHMODULEFLAGS and not SHLDFLAGS * examples/sotest/lib/dynload/dynload.c - Test case for loading of ET_DYN shared objects * examples/sotest/lib/dynload/.gitignore - Exclude built object from git * examples/sotest/sotest_main.c - Load and invoke the dynload test

acassis · 2024-01-05T22:56:53Z

@nealef any idea why the CI is failing in the CI ?
Please run the config update to verify is all boards defconfig are correct:

$ ./tools/refresh.sh --silent --defaults all

It could spend about 1h depending on your machine speed

nealef · 2024-01-08T02:12:51Z

The various .def files need to be updated for the SHMODULEFLAGS/SHCCFLAGS. There doesn't seem to be a consistent place to put them depending on the board type. This is what I am proposing to get things working:

--- a/arch/risc-v/src/common/Toolchain.defs
+++ b/arch/risc-v/src/common/Toolchain.defs
@@ -104,8 +104,11 @@ ifneq ($(CONFIG_CXX_RTTI),y)
   ARCHCXXFLAGS += -fno-rtti
 endif

+SHMODULEFLAGS = -Bsymbolic -G -Bdynamic
+
 ifeq ($(CONFIG_ARCH_RV32),y)
 LDFLAGS += -melf32lriscv
+SHMODULEFLAGS += -melf32lriscv
 else
 LDFLAGS += -melf64lriscv
 endif
diff --git a/boards/arm64/qemu/qemu-armv8a/scripts/Make.defs b/boards/arm64/qemu/qemu-armv8a/scripts/Make.defs
index fce2c86eea..2b76e1b08d 100644
--- a/boards/arm64/qemu/qemu-armv8a/scripts/Make.defs
+++ b/boards/arm64/qemu/qemu-armv8a/scripts/Make.defs
@@ -46,6 +46,8 @@ CMODULEFLAGS = $(CFLAGS)
 LDMODULEFLAGS = -r -e module_initialize
 LDMODULEFLAGS += -T $(call CONVERT_PATH,$(TOPDIR)/libs/libc/modlib/gnu-elf.ld)

+SHMODULEFLAGS = -Bsymbolic -G -Bdynamic
+
 CELFFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
 CXXELFFLAGS = $(CXXFLAGS) -mlong-calls # --target1-abs

diff --git a/boards/sim/sim/sim/scripts/Make.defs b/boards/sim/sim/sim/scripts/Make.defs
index 4a6670117d..9c2d84c269 100644
--- a/boards/sim/sim/sim/scripts/Make.defs
+++ b/boards/sim/sim/sim/scripts/Make.defs
@@ -268,7 +268,7 @@ else
 endif

 SHCCFLAGS = -fPIC -fPIE -fvisibility=default
-SHLDFLAGS = -shared -Bsymbolic -Bdynamic -G
+SHMODULEFLAGS = -shared -Bsymbolic -Bdynamic -G

 ifeq ($(CONFIG_DEBUG_LINK_MAP),y)
   ifeq ($(CONFIG_HOST_MACOS),)
@@ -280,6 +280,6 @@ ifeq ($(CONFIG_SIM_M32),y)
   LDLINKFLAGS += -melf_i386
   LDFLAGS += -m32
   LDMODULEFLAGS += -melf_i386
-  SHLDFLAGS += -melf_i386
+  SHMODULEFLAGS += -melf_i386
   LDELFFLAGS += -melf_i386
 endif

xiaoxiang781216 · 2024-05-30T11:03:00Z

@acassis this pr doesn't pass ci why do you merge it?

acassis · 2024-05-30T13:01:15Z

Seems like the issue was not related, let me double check

almir-okato · 2024-05-30T15:58:08Z

@acassis @xiaoxiang781216 could this merge be reverted? It breaks xtensa build on upstream CI and also breaks our internal CI.

acassis · 2024-05-30T15:59:58Z

@almir-okato instead reverting the PR we could fix xtensa:

The arch/xtensa/src/esp32s3/esp32s3_start.c has an entry point __start that calls __esp32s3_start it also has code such as:

/****************************************************************************
 * Private Function Prototypes
 ****************************************************************************/

#ifdef CONFIG_ESP32S3_APP_FORMAT_MCUBOOT
noreturn_function void __start(void);
#endif

/****************************************************************************
 * Private Data
 ****************************************************************************/

#ifdef CONFIG_ESP32S3_APP_FORMAT_MCUBOOT
HDR_ATTR static void (*_entry_point)(void) = __start;
#endif

acassis · 2024-05-30T16:01:19Z

@almir-okato could you please confirm it worked for you, then I will submit it.

almir-okato · 2024-05-30T16:10:59Z

@almir-okato instead reverting the PR we could fix xtensa:

The arch/xtensa/src/esp32s3/esp32s3_start.c needs an entry point __start that calls __esp32s3_start it also has code such as:

/****************************************************************************
 * Private Function Prototypes
 ****************************************************************************/

#ifdef CONFIG_ESP32S3_APP_FORMAT_MCUBOOT
noreturn_function void __start(void);
#endif

/****************************************************************************
 * Private Data
 ****************************************************************************/

#ifdef CONFIG_ESP32S3_APP_FORMAT_MCUBOOT
HDR_ATTR static void (*_entry_point)(void) = __start;
#endif

@acassis the entry point __start already exists on esp32s3_start.c, the build complains about a symbol _start (only one '_').
However, this is not the only issue, the ESP32-S2 test execution on our internal CI also fails.

acassis · 2024-05-30T16:24:42Z

@almir-okato yes, but I noticed other chips has this same __start and this report the _start issue

What are the issues on ESP32-S2? Are they also same __start?

acassis · 2024-05-30T16:37:36Z

@almir-okato renaming __esp32s3_start to __start could fix the issue

almir-okato · 2024-05-30T16:51:43Z

@acassis I'm adding @tmedicci to the loop.

tmedicci · 2024-05-30T18:01:05Z

@acassis , this issue is not related directly to ESP32-S2 or ESP32-S3, neither with xtensa-only devices. Please check this comment: there is still pending work. While this is incomplete, sotest will fail to be built and work as expected.

The error message is (for RISC-V, for instance):

riscv-none-elf-ld: /nuttx/nuttxspace/nuttx/staging/libapps.a(sot_symtab.c.nuttx.nuttxspace.apps.examples.sotest_1.o):(.rodata.g_sot_exports+0x4): undefined reference to `_start'

_start refers to an undefined symbol in apps/examples/sotest/lib/fsroot/dynload. mksymtab generates the following content to the apps/examples/sotest/lib/sot_symtab.c:

#include <nuttx/compiler.h>
#include <nuttx/symtab.h>

extern void *_start;
extern void *syslog;
extern void *vsyslog;

const struct symtab_s g_sot_exports[] = 
{
  {"_start", &_start},
  {"syslog", &syslog},
  {"vsyslog", &vsyslog},
};

const int g_sot_nexports = sizeof(g_sot_exports) / sizeof(struct symtab_s);

There is no relation to __esp32s3_start or __start as @almir-okato said. I am submitting a PR to revert this until we have it properly fixed. In this case, CI was able to capture the errors (I could not check because the artifacts are gone, but it is a build issue)

acassis · 2024-05-30T18:52:29Z

Thank you @tmedicci and @almir-okato ! I was thinking the issue are happening because esp32s3 was using a different __start name

nealef · 2024-05-31T16:38:04Z

The _start symbol is being placed int sot_symtab.c by tools/mksymtab.sh which is using the nm command to find all the unresolved symbols in a .a or .so file (I don't have insight into which object is being looked at in this particular instance). _start is the default symbol for the entry point on an executable unless overridden in the link command line --entry. Should whatever is building the object for xtensa use the --entry with the __esp32s3_start argument? I am assuming this is for the dynload test within sotest. If true then I need to find the best place to specify the --entry option or the .ld script.

nealef · 2024-06-03T20:03:20Z

It's not the entry point that's causing the grief as the *.ld script files all specify an entry point of __start so it seems related to the binary being examined by the nm command. Is there anyway to get hold those artifacts? This seems to feature in the issue: apache/nuttx#12356 (comment).

I don't understand enough about the differences between various xtensa boards to determine whether it is significant that for esp32 and esp32s2 the user_space ld file has definitions for _start:

boards/xtensa/esp32/common/scripts/esp32_rom.ld:PROVIDE ( _start = 0x40000704 );
boards/xtensa/esp32s2/common/scripts/esp32s2_rom.ld:PROVIDE ( _start = 0x4000726c );

The s3 version of this file looks radically different.

acassis · 2024-06-03T21:57:15Z

@nealef ESP32 has a libc and other features inside their internal ROM that applications could reuse, it helps to reduce the application size, since the application don't need to be linked with an external libc to work for example (although on NuttX was have the possibility to use our libc instead). Since _start exists in the ROM we cannot have it in the esp32_start.c

acassis · 2024-06-03T21:58:32Z

@nealef actually I think we can use other symbol to indicate that _start at 0x40000704. @tmedicci what do you think? Do you see any issue of this idea?

acassis · 2024-06-04T22:37:21Z

@tiagojbalmeida @almir-okato I discovered that providing the _start symbol at ROM ldscript fixes the issue. Please note that definition exists for ESP32 and ESP32S2, but is missing for ESP32S3.

I used the same definition from ESP32S2 (probably needs to be a different location)

$ git diff
diff --git a/boards/xtensa/esp32s3/common/scripts/esp32s3_rom.ld b/boards/xtensa/esp32s3/common/scripts/esp32s3_rom.ld
index 263b9c8874..9317a862e0 100644
--- a/boards/xtensa/esp32s3/common/scripts/esp32s3_rom.ld
+++ b/boards/xtensa/esp32s3/common/scripts/esp32s3_rom.ld
@@ -53,6 +53,7 @@ ets_printf = 0x400005d0;
 ets_install_putc1 = 0x400005dc;
 ets_install_uart_printf = 0x400005e8;
 ets_install_putc2 = 0x400005f4;
+PROVIDE ( _start = 0x4000726c );
 PROVIDE( ets_delay_us = 0x40000600 );
 ets_get_stack_info = 0x4000060c;
 ets_install_lock = 0x40000618;

tmedicci · 2024-06-05T11:58:41Z

@acassis and @nealef :

The _start defined in ROM is defined under PROVIDE, which means that the system can override it. This is not the problem because we don't use it. Again, the issue is not related to xtensa's, it happens even for RISC-V, as I commented here.

Alan, adding the _start to the linker just provides the symbol with a wrong reference. Th point is why is this symbol being evaluated by the dynload test:

#include <nuttx/compiler.h>
#include <nuttx/symtab.h>

extern void *_start;
extern void *syslog;
extern void *vsyslog;

const struct symtab_s g_sot_exports[] = 
{
  {"_start", &_start},
  {"syslog", &syslog},
  {"vsyslog", &vsyslog},
};

const int g_sot_nexports = sizeof(g_sot_exports) / sizeof(struct symtab_s);

@nealef, both xtensa and RISC-V already define the entrypoint in arch/xtensa/src/Makefile and nuttx/arch/risc-v/src/Makefile and it is defined as __start (double _). The question is: why _start (single _) is used instead of __start (double _) in the dynload test app?

acassis · 2024-06-05T12:37:44Z

@tmedicci I agree, we need to discover why this symbol is generated and evaluated for Xtensa and RISC-V and doesn't happen to ARM. Probably because all ARM chips define _start at their arch xxx_start.c.

Yes, the _start for ESP32-S3 is wrong, I only defined it equal ESP32-S2 to confirm that it was enough to make the linker happy. We need to understand the root causes.

nealef · 2024-06-05T19:00:35Z

@tmedicci The script tools/mksymtab.sh is processing some artifacts of the build process and finding an undefined symbol and placing it in the sot_symbols.c file. I can't tell in which artifact it's finding it but I assume it's in the .so file. @acassis Can I get access to where you are building things to find where that reference is? _start is the default symbol if no --entry is specified. It makes me wonder if we need to define CONFIG_USER_ENTRYPOINT for this platform? However, I'd like to take a look at the artifacts before pursuing this line of investigation.

nealef · 2024-06-05T19:14:18Z

@tmedicci When I build the dyntest .so file I use a variable $(SHMODULEFLAGS). I think this needs updating for the platform to include the --entry=__start option. Here's the dynload/Makefile section of interest:

$(OBJS): %$(OBJEXT): %.c
        @echo "MODULECC: $<"
        $(Q) $(MODULECC) -c $(CMODULEFLAGS) $(SHCCFLAGS) $< -o $@

$(BIN): $(OBJS)
        @echo "MODULELD: $<"
        $(Q) $(MODULELD) $(SHMODULEFLAGS) $(LDLIBPATH) -o $@ $^ $(LDLIBS)

Here's where we set it for riscv:

--- a/arch/risc-v/src/common/Toolchain.defs
+++ b/arch/risc-v/src/common/Toolchain.defs
@@ -104,8 +104,11 @@ ifneq ($(CONFIG_CXX_RTTI),y)
   ARCHCXXFLAGS += -fno-rtti
 endif

+SHMODULEFLAGS = -Bsymbolic -G -Bdynamic
+
 ifeq ($(CONFIG_ARCH_RV32),y)
 LDFLAGS += -melf32lriscv
+SHMODULEFLAGS += -melf32lriscv
 else
 LDFLAGS += -melf64lriscv
 endif

nealef · 2024-06-06T16:24:27Z

@tmedicci - @acassis tested with this patch and it worked:

diff --git a/arch/xtensa/src/lx6/Toolchain.defs b/arch/xtensa/src/lx6/Toolchain.defs
index 1be4627c92..187a27a7cf 100644
--- a/arch/xtensa/src/lx6/Toolchain.defs
+++ b/arch/xtensa/src/lx6/Toolchain.defs
@@ -124,6 +124,8 @@ endif

 LDFLAGS += -nostdlib

+SHMODULEFLAGS = -Bsymbolic -G -Bdynamic --entry=__start
+
 # Optimization of unused sections

 ifeq ($(CONFIG_DEBUG_OPT_UNUSED_SECTIONS),y)
diff --git a/arch/xtensa/src/lx7/Toolchain.defs b/arch/xtensa/src/lx7/Toolchain.defs
index 710b19677d..d7d0b01f2d 100644
--- a/arch/xtensa/src/lx7/Toolchain.defs
+++ b/arch/xtensa/src/lx7/Toolchain.defs
@@ -128,6 +128,8 @@ endif

 LDFLAGS += -nostdlib

+SHMODULEFLAGS = -Bsymbolic -G -Bdynamic --entry=__start
+
 # Optimization of unused sections

 ifeq ($(CONFIG_DEBUG_OPT_UNUSED_SECTIONS),y)

xiaoxiang781216 reviewed Sep 4, 2023

View reviewed changes

examples/sotest/lib/dynload/dynload.c Outdated Show resolved Hide resolved

masayuki2009 mentioned this pull request Sep 4, 2023

Fix loading of ET_DYN type of shared objects apache/nuttx#10470

Merged

xiaoxiang781216 requested review from pkarashchenko and acassis September 7, 2023 07:54

nealef force-pushed the dynload-fix branch from fb62cca to 1d0df9c Compare September 7, 2023 13:56

pkarashchenko approved these changes Sep 8, 2023

View reviewed changes

nealef force-pushed the dynload-fix branch from def1288 to 0293b87 Compare September 13, 2023 07:17

pkarashchenko reviewed Sep 15, 2023

View reviewed changes

examples/sotest/lib/dynload/dynload.c Outdated Show resolved Hide resolved

nealef force-pushed the dynload-fix branch from 0293b87 to bb32dd2 Compare September 18, 2023 01:21

nealef force-pushed the dynload-fix branch from bb32dd2 to 192c8a6 Compare September 22, 2023 03:22

nealef force-pushed the dynload-fix branch from 192c8a6 to bca9d9c Compare September 26, 2023 02:01

nealef force-pushed the dynload-fix branch from c5565f3 to 6b951e0 Compare December 12, 2023 23:48

acassis merged commit 72eaed8 into apache:master May 29, 2024
23 of 25 checks passed

tmedicci mentioned this pull request May 30, 2024

Revert "Add loading of ET_DYN shared object test to sotest" to enable CI to run properly #2408

Merged

Add loading of ET_DYN shared object test to sotest #2026

Add loading of ET_DYN shared object test to sotest #2026

Conversation

nealef commented Sep 4, 2023

Summary

Impact

Testing

xiaoxiang781216 commented Sep 7, 2023

pkarashchenko commented Sep 7, 2023 • edited Loading

pkarashchenko commented Sep 8, 2023 • edited Loading

nealef commented Sep 12, 2023

pkarashchenko commented Sep 12, 2023

nealef commented Sep 12, 2023

nealef commented Sep 12, 2023 • edited Loading

xiaoxiang781216 commented Sep 21, 2023

nealef commented Sep 21, 2023 via email

nealef commented Sep 21, 2023

xiaoxiang781216 commented Sep 21, 2023

nealef commented Sep 21, 2023

xiaoxiang781216 commented Sep 22, 2023

nealef commented Sep 22, 2023

xiaoxiang781216 commented Sep 22, 2023

nealef commented Sep 22, 2023

nealef commented Sep 26, 2023

xiaoxiang781216 commented Sep 26, 2023 • edited Loading

nealef commented Sep 26, 2023

acassis commented Dec 12, 2023

xiaoxiang781216 commented Dec 12, 2023

nealef commented Dec 12, 2023

acassis commented Jan 5, 2024

nealef commented Jan 8, 2024

xiaoxiang781216 commented May 30, 2024 • edited Loading

acassis commented May 30, 2024

almir-okato commented May 30, 2024

acassis commented May 30, 2024 • edited Loading

acassis commented May 30, 2024

almir-okato commented May 30, 2024

acassis commented May 30, 2024

acassis commented May 30, 2024

almir-okato commented May 30, 2024

tmedicci commented May 30, 2024

acassis commented May 30, 2024

nealef commented May 31, 2024

nealef commented Jun 3, 2024

acassis commented Jun 3, 2024

acassis commented Jun 3, 2024

acassis commented Jun 4, 2024

tmedicci commented Jun 5, 2024

acassis commented Jun 5, 2024

nealef commented Jun 5, 2024

nealef commented Jun 5, 2024

nealef commented Jun 6, 2024

pkarashchenko commented Sep 7, 2023 •

edited

Loading

pkarashchenko commented Sep 8, 2023 •

edited

Loading

nealef commented Sep 12, 2023 •

edited

Loading

xiaoxiang781216 commented Sep 26, 2023 •

edited

Loading

xiaoxiang781216 commented May 30, 2024 •

edited

Loading

acassis commented May 30, 2024 •

edited

Loading