casaroli opened a new pull request, #20382:
URL: https://github.com/apache/nuttx/pull/20382

   ## Summary
   
   Part of the FDPIC series.  An architecture that sets 
`CONFIG_ARCH_USE_DATA_HEAP` gives a loaded module its data from 
`up_dataheap_memalign()`.  The ELF loader honours that for every object except 
an FDPIC one: an FDPIC object allocates its writable segment on its own, and 
that allocation and the two places that free it still use `lib_memalign()` and 
`lib_free()`.  Its text already honours `CONFIG_ARCH_USE_TEXT_HEAP`.
   
   This makes the FDPIC data allocation, and its frees in `elf_unload.c` and 
`elf_remove.c`, use the data heap when it is enabled.
   
   ## Impact
   
   Only a build with `CONFIG_FDPIC` and `CONFIG_ARCH_USE_DATA_HEAP` changes.  
In the tree that is `mps3-an547`, whose text and data heaps are in SRAM2.
   
   In a flat build the module ran before too, just out of the wrong heap.  In a 
protected build it did not: the ordinary heap is kernel memory there, so the 
module took a data access violation on its first access to its data.  Making 
`mps3-an547:knsh` run modules also needs its SRAM2 heaps mapped for user code, 
which is a separate change.
   
   ## Testing
   
   `mps3-an547:nsh` under QEMU with `CONFIG_FDPIC`, 
`CONFIG_ARCH_USE_TEXT_HEAP`, `CONFIG_ARCH_USE_DATA_HEAP` and xipfs on a RAM MTD 
(the xipfs mount is local to the test, not part of this PR), running `fdpicxip`:
   
   ```
   before:  Loading sections - text: 0x100d848.358 data: 0x1007220.180
            Loading sections - text: 0x100d848.358 data: 0x104e480.180
   after:   Loading sections - text: 0x100d848.358 data: 0x21000000.180
            Loading sections - text: 0x100d848.358 data: 0x21000180.180
            [inst 1] 11 21 31 41 51 61 71 81
            [inst 2] 12 22 32 42 52 62 72 82
            === done ===
   ```
   
   Both instances share the text in place and run to the end in both cases; 
after the change their data is in the SRAM2 data heap.
   
   `tools/checkpatch.sh -g` passes.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to