[Discussion] Doubts regarding nxflat supported features

[Abhishek-05]

Hello all!

1. Is c++ supported by nxflat? binfmt/libelf seems to support cpp and I can see some cpp related code in it. But binfmt/nxflat doesn't seem to have any cpp related code. I am confused because there is test code present in apps for cpp https://github.com/apache/nuttx-apps/tree/master/examples/nxflat/tests/hello%2B%2B
2. Is it possible to import global variables in nxflat application? I have read in xflat that it doesn't support global variables sharing across modules and we need to provide a wrapper function around the variables. Is this the same case with nxflat too?

Thanks!

[acassis]

@Abhishek-05 is an "re-implementation" of XFLAT https://xflat.sourceforge.net/ (also from Mr. Greg Nutt) to work on NuttX.

Probably there is nobody using it, but there is a repo with instruction to build the tools needed: https://github.com/btashton/nxflat

1. Probably these examples were build using uClibc++, so probably it will not work with LLVM libcxx
2. Yes, it doesn't allow share symbols like ELF, but it supports XIP (so you can run you application from flash, maybe even using it with progmem! )

Maybe @btashton or @patacongo could give you more details, I never used it.

[btashton]

My version has been used and fixes some important bugs.

[acassis]

@btashton should we move it to inside nuttx/tools/ ?

As I said I think there are not much people using it, and "currently" you should be the only one using it. Maybe we could make it more mainstream again.

[btashton]

No it is explicitly GPL

[patacongo]

XFLAT ran on uCLinux and supported full MMU-less shared libraries. So NxFlat is only "inspired" by XFLAT. More info about XFLAT:

• https://xflat.sourceforge.net/
• https://sourceforge.net/projects/xflat/

(That stuff dates back to around 2002!)

Some relevant NxFLAT documentation:

• https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139630111
• https://cwiki.apache.org/confluence/display/NUTTX/NxFlat
• https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Binary+Formats

I think there is a GIT Issue that describes all known NxFLAT problems, but I couldn't find it.

Basic C++ is supported, but little more than C with classes (but it does apparently support static constructors/destructors since they are included in the referenced test). I suspect if you use full featured C++ you will run across some issues (perhaps with things like exception unwinding which has never been tried).

NxFLAT runs PIC/PID. So all global data is GOT relative. That means that you have to have a pair of values to access global data: The GOT offset and the PID base (like Linux). If accessor functions are used, they can automatically bind these into a single, absolute address.

Why PIC/PID? Same reason that Linux shared libraries are PIC/PID. It allows multiple instances of a program running PIC from a single program .text image in FLASH. Since the FLASH location is arbitrary, it must be PIC. (the reasoning is a little different in Linux, but the end result is the same).

Each program instance differs in that it must have its own copy of program data: One .text section in FLASH, multiple .data/.bss/etc. data sections in RAM. Hence, the program in FLASH must also run PID in order to access the correct data instance for the task.

PIC = Position independent code
PID = Position independent data
GOT = Global offset table at a fixed, known offset from the .text section

[anjiahao1]

I am implementing PIC position-independent code running in nuttx, which allows the image to run at any location, and you can choose whether it is xip. It may take a little debugging time before it can run perfectly.

[patacongo]

No it is explicitly GPL

This is why we need a github nuttx-tools repository that holds non-Apache, GPL code.

These look like replacement tools for https://bitbucket.org/nuttx/buildroot/src/master/toolchain/nxflat/ , extracted from buildroot to build standalone?

[patacongo]

I am implementing PIC position-independent code running in nuttx, which allows the image to run at any location, and you can choose whether it is xip. It may take a little debugging time before it can run perfectly.

There are not many binary formats that will let you run XIP. No other is supported but NxFLAT by NuttX currently. The reason is because when, say ELF code, is loaded. It modifies the text section. That precludes running XIP and means that you have to have a separate text and data memory allocation for each instance of a program.

XIP can only be supported by NxFLAT if the underlying file system also stores file data contiguously and aligned in memory. Currently on ROMFS can be used. So to have XIP, you need ROMFS + NxFLAT.

Or are you inventing something new???? If so I would love to hear the details of what you are doing.

[That should be a different Issue or email discussion. We don't want to get too off-topic in this one!]

[anjiahao1]

I am implementing PIC position-independent code running in nuttx, which allows the image to run at any location, and you can choose whether it is xip. It may take a little debugging time before it can run perfectly.

There are not many binary formats that will let you run XIP. No other is supported but NxFLAT by NuttX currently. The reason is because when, say ELF code, is loaded. It modifies the text section. That precludes running XIP and means that you have to have a separate text and data memory allocation for each instance of a program.

XIP can only be supported by NxFLAT if the underlying file system also stores file data contiguously and aligned in memory. Currently on ROMFS can be used. So to have XIP, you need ROMFS + NxFLAT.

Or are you inventing something new???? If so I would love to hear the details of what you are doing.

[That should be a different Issue or email discussion. We don't want to get too off-topic in this one!]

I made the entire Nuttx image into position-independent code, so that the Nuttx image can run in different locations. The implementation principle should be consistent with NxFLAT

[xiaoxiang781216]

I am implementing PIC position-independent code running in nuttx, which allows the image to run at any location, and you can choose whether it is xip. It may take a little debugging time before it can run perfectly.

There are not many binary formats that will let you run XIP. No other is supported but NxFLAT by NuttX currently. The reason is because when, say ELF code, is loaded. It modifies the text section. That precludes running XIP and means that you have to have a separate text and data memory allocation for each instance of a program.

Compiler can generate the position independent ELF too, so there is no big difference between ELF and NxFLAT regarding PIC/GOT.

XIP can only be supported by NxFLAT if the underlying file system also stores file data contiguously and aligned in memory. Currently on ROMFS can be used. So to have XIP, you need ROMFS + NxFLAT.

ROMFS + ELF(compiled with -pic) can support XIP too.

Or are you inventing something new???? If so I would love to hear the details of what you are doing.

Not really new, the unmodified toolchain could be used as before (the important advantage than NxFLAT), the code related to binfmt/elf and relocation need to be extended.

[That should be a different Issue or email discussion. We don't want to get too off-topic in this one!]

[patacongo]

I made the entire Nuttx image into position-independent code, so that the Nuttx image can run in different locations. The implementation principle should be consistent with NxFLAT

Hmmm.. Interesting. Couldn't you also just make the NuttX image a relocatible binary? Would that be easier and result in more efficient code (since there is no PIC offset).

[patacongo]

Compiler can generate the position independent ELF too, so there is no big difference between ELF and NxFLAT regarding PIC/GOT.

In a usual Linux process the GOT immediately follows .text and so is at a pre-determined, PC-relative location. But if ELF is running PIC in FLASH, then the GOT cannot be at that location after .text, it would have to lie in RAM.

If the GOT/.bss/,data/etc RAM memory is allocated from the heap, then it would lie at an arbitrary location and the loaded code would have to be PID as well. If it is the whole NuttX system, then I suppose you can assume that certain memory resources are at fixed, pre-determined addresses. Then you could avoid PID.

The tools probably won't support those latter cases and you would probably have to run GOT-less with some custom code to initialize the PIC/PID registers.

[xiaoxiang781216]

@anjiahao1 could give more detailed info.

[Abhishek-05]

Thanks a lot @patacongo , @btashton and @acassis. I will go through nxflat and xflat documentation provided above. @anjiahao1 and @xiaoxiang781216 , I'm not looking for running the nuttx image with pic but to load and execute programs during runtime. Till now I was able to use elf, but due to memory constraints I was checking for loaders that support XIP. Again, thanks a lot everyone for providing helpful insights. Once the discussion regarding nuttx pic is concluded, this issue can be closed.

[acassis]

@Abhishek-05 what microcontroller are you using?

[Abhishek-05]

I'm using RTL8721CSM.

[acassis]

Hmm, but the mainline doesn't have support to this chip, are you using RTL8720C as base?

[Abhishek-05]

I was using Tizenrt (which is based on Nuttx) as it has support for rtl8721csm. While searching for alternatives to elf I have come across nxflat and wanted to know more about it.

[acassis]

Nice! I didn't know that TizenRT had support to this chip. It should be nice if they contribute these things back to mainline

[patacongo]

Nice! I didn't know that TizenRT had support to this chip. It should be nice if they contribute these things back to mainline

They are using a 9 year old fork of NuttX. It probably cannot be used with the current Apache NuttX without changes. It is licensed Apache 2.0 so I suppose it could come in as 3rd party code.

https://github.com/Samsung/TizenRT/tree/master/os/arch/arm/src/amebad

Changes to TizenRT/os are light. They don't seem to be taking a lot from Apache NuttX

[patacongo]

In a usual Linux process the GOT immediately follows .text and so is at a pre-determined, PC-relative location. But if ELF is running PIC in FLASH, then the GOT cannot be at that location after .text, it would have to lie in RAM.

You could probably eliminate PID and use all PC-relative data like Linux if you came up with a creative way to position the data segment virtual address in RAM right after the text segment in FLASH (although it would shadow the physical FLASH). Using the MMU to also force the text segment in FLASH to virtual address zero, you could also eliminate the requirement for PIC.

NxFLAT was intended for use without an MMU. It could be extended with MMU usage like this as well, but there is really no point in that.