-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulator export fails #11863
Comments
Hi @nicolas71640 do you need to use CMakefile? Maybe the export building using Makefile still working. There is an old Documentation (that didn't migrate to our new Documentation/) here: https://cwiki.apache.org/confluence/display/NUTTX/Building+NuttX+with+Applications+Outside+of+the+Source+Tree |
@xuxin930 since you are fixing the CMake, could you please take a look? |
hi @acassis @nicolas71640 You can first consider using the Makefile base compilation method. I will mark an action and try to add this feature of CMake as soon as possible. |
I think there is a quiproquo here: we are using CMake as our project tool, but we build NuttX with Makefile. The exported CMake toolchain file is based on the export.sh script and I imagine that the variables are coming from the Makefile mechanism since it is the one we are using to build NuttX. My understanding is that NuttX Makefile or CMake should do the same things (maybe it is buggy) but at the end, the NuttX export archive consumption is independent of the NuttX procedure to build it, using Make or CMake to do so |
Thank you all for your help. Am I doing something wrong ? Just followed a readme that I've found in the source :
|
@nicolas71640 I got same errors you got:
Probably it is happening because normally people use it mainly with real boards to integrating NuttX kernel as library and avoid using our building system in production. @xiaoxiang781216 did you or your team use make export/import with simulator? |
Yes, but only for Makefile |
@xiaoxiang781216 What do you mean by "only for Makefile" ? |
we export and import only with make, not try export with make and build with cmake. Your usage doesn't coverage by daily ci or even mention in document. |
I'm not using cmake. I'm using make targets "export" and "import". |
Hi everyone ! As the simulator runs on the host, it must replace some of its symbols by nuttx symbol. For instance, the method puts, shouldn't print something on the output but use the "mocked" serial console of nuttx (passing through the UART for instance). This map of symbols is defined in nuttx-names.in. So the first step of the linking, is to make a "partially linked" lib (nuttx.rel) containing nuttx code, replacing the libc symbols by its own. Then the second step is to take this nuttx.rel lib and link it to the interface with the host (all the HOSTOBJS). An other object is linked in this final binary is the sim_head.o, containing the entry point of the simulator. Did I understand correctly what's happening here ? Now, for the export. My first though was that we needed this nuttx.rel to be linked on the final target. So put that nuttx.rel in the archive. Apparently this is not the strategy. I see that we export the nuttx-names.dat in the archive (in libs/ ). Why not, but I can't find where this file is used to replace the symbols in the import scripts... An idea ? Therefore, I have absolutely no idea how the simulator export could work... |
@nicolas71640 I think your assumptions/findings are mostly corrects. @xiaoxiang781216 @anchao any idea how to make the simulator to export the symbols correctly? |
Yes, sim has verry special linking process, which isn't fit well with the current import/export
We didn't try export/import sim before because:
Both make the usage of sim export/import is very seldom. |
We wanted to use the simulator for test purposes. We thought it would be a simple way to have our application packaged with nuttx in a very testable/instrumentable environment as linux. We are also planning to have tests on the board, but these tests would be slower and less instrumentable, so we wanted to have both. The other option was a qemu obviously, but we thought the simulator would be lighter and faster, and maybe simpler to set up in our CI. Now, if you have advices, we are willing to rethink our strategy. Exporting the nuttx.rel (and nuttx.ld), I have actually succeed to link the final binary, BUT not only with ld, but passing via gcc (as we do it the sim Makefile). I assume it uses standard libs that I don't put with ld (but I can't figure out which one I'm missing with ld). So I f I want to make the export/import stuff works for the sim, I'll have to add some var, and a specific strategy only for the simulator... |
Qemu may better than sim in this case, because both toolchain and export/import is same as the real device. |
All right ! |
I am trying to build my own app using the export target with the simulator. And I've run into few issues :
To be clear, here's the procedure I following :
ld: unrecognized option '-Wl,--gc-sections'
Indeed in the target.cmake of the export the LDFLAGS are :
"-Wl,--gc-sections -Wl,-Ttext-segment=0x400000 -Wl,-Map=/home/nuttxspace/nuttx/nuttx.map")
Which can not work because we passing the -Wl argument directly to the linker... First issue.
Then the linker returns this error :
ld: read in flex scanner failed
With some research, this error is a the way of the linker to say that it can't read some arguments. Some tests showed me that the -T{LINKER_SCRIPT} argument (toolchain.cmake) was the culprit.
Here's the line where we set the LINKER_SCRIPT variable :
set(LINKER_SCRIPT ${NUTTX_PATH}/scripts/${LDNAME})
Problem, in the target.cmake the ${LDNAME} is empty:
set(LDNAME "")
The LDNAME variable is set in the Export.mk file :
For now, I've stopped there the investigation, but I will go further in this. These errors make me think that the simulator export is bugged. What do you think ? Is it possible that it isn't really used and it is now outdated ? Or is there something I'm doing wrong ?
By the way, without the export, it works perfectly well (tested with nsh).
ping @leducp
The text was updated successfully, but these errors were encountered: