I need memory to be setup in a given way immediately when simulation starts before any instructions are executed.
I understand that this is essentially what the ELF loader does to load the main executable, but trying to pass fs.py --kernel multiple times appears to have no effect.
I could try to hack that data into my mail ELF executable with the linker script, but it would be much more convenient if I could avoid this and just provide either raw bytes on the CLI, or give a raw binary file to be loaded at a given address.
QEMU for example exposes this type of functionality with -device loader.
Tested in gem5 f5f9ca46258ac2ded8f3402e5d271a18f8400183 (April 2020) I can achieve this with:
configs/example/fs.py \
--param 'system.workload.extras = "mydata.raw"' \
--param 'system.workload.extras_addrs = 0x83000000' \
where mydata.raw contains the raw data to be loaded, and 0x83000000 is the base physical address to load to.
Both of those parameters are arrays, so you can load multiple raw binaries for example with:
configs/example/fs.py \
--param 'system.workload.extras = ["mydata.raw", "mydata2.raw"]' \
--param 'system.workload.extras_addrs = [0x83000000, 0x84000000]' \
This can be used for example to pass information to baremetal executables. For example, this could be used to implement baremetal command line arguments of a C program.
Related
I designed RISCV32IM processor, and I used "riscv32-unknown-elf-gcc" to generate code for testing.
However, the PC(instruction memory address) value and data memory address of the generated code had arbitrary values. I used this command:
riscv32-unknown-elf-gcc -march=rv32im -mabi=ilp32 -nostartfiles test.c
Can I know if I can set the instruction and data memory address I want?
Thanks.
Thank you for answer.
I designed only HW, and this is my first time using the SW tool chain.
Even if my question is rudimentary, please understand.
The figure is the result of the "-v" option.
enter image description here
I can't modify the script file because I use riscv tool chain in DOCKER environment.
So, I tried to copy the script file (elf32lriscv.x), modify it.
I modified it to 0x10000 ==> 0x00000.
The file name of the copied script is "test5.x".
And it was executed as follows.
What am I doing wrong?
enter image description here
The riscv compiler is using the default linker script to place text and date section... .
If you add -v option to your command line riscv32-unknown-elf-gcc -v -march=rv32im -mabi=ilp32 -nostartfiles test.c, you will see the linker script used by collect 2 ( normally it will be -melf32lriscv . you can find the linker script in ${path_to_toolchain}/riscv32-unknown-elf/lib/ldscripts/ (the default one is .x).
You can also use riscv32-unknown-elf-ld --verbose like explained by #Frant. However , you need to be careful if the toolchain was compiled with enable multilib and you compile for rv64 but the default is rv32 or vice versa. It is not the case probably, but to be sure you can specify the arch with -A elf32riscv for an rv32.
To Set the addresses you can create your own linker script or copy and modify the default one. You can only modify the executable start like explained by #Frant or make more modification and place whatever you want where you want.
Once your own linker script ready you can pass it to the linker with -Wl,-T,${own_linker_script }. you command will be riscv32-unknown-elf-gcc -march=rv32im -mabi=ilp32 -nostartfiles test.c -Wl,-T,${own_linker_script }
I am attached to a running proces using dbx on AIX. There is a bug in the program, the offset in the opcode below is 0x9b8, but should be 0xbe8:
(dbx) listi 0x100001b14
0x100001b14 (..........+0x34) e88109b8 ld r4,0x9b8(r1)
I am able to fix that using the command below:
(dbx) assign 0x100001b14 = 0xe8810be8
but that affects only the running process and its memory. How can I change the on disk binary? I am not able to locate the pattern e88109b8 in the binary file,
otherwise I would use e.g. dd utility to patch it.
Best regards,
Pavel Filipensky
I'm creating a library for micro-controller which as part of it's source will have couple of usage examples.
All CMakeList.txt files for the examples look very similar:
set(ESP_TARGET_FW1 "${CMAKE_CURRENT_BINARY_DIR}/${ESP_FW1}.bin")
set(ESP_TARGET_FW2 "${CMAKE_CURRENT_BINARY_DIR}/${ESP_FW2}.bin")
add_executable(esp_main main.c ${ESP_USER_CONFIG})
target_include_directories(esp_main PUBLIC include)
target_link_libraries(esp_main esp_sdo phy pp net80211)
# Create ESP8266 binary files.
add_custom_command(
OUTPUT
${ESP_TARGET_FW1} ${ESP_TARGET_FW2}
COMMAND
${ESPTOOL_PATH} elf2image $<TARGET_FILE:esp_main> -o ${CMAKE_CURRENT_BINARY_DIR}/
DEPENDS
esp_main
)
# Flash binary files to the device.
add_custom_target(esp_main_flash
COMMAND
${ESPTOOL_PATH} -p ${ESP_PORT} -b ${ESP_BAUD} write_flash ${ESP_FW1} ${ESP_TARGET_FW1} ${ESP_FW2} ${ESP_TARGET_FW2}
DEPENDS
${ESP_TARGET_FW1} ${ESP_TARGET_FW2}
)
Only the name of the example (esp_main) changes and where the generated binary files are created.
I'm looking to somehow parameterize add_custom_command and add_custom_target in case like this. Ideally include some file and have it define esp_main_flash target and custom command.
In CMake the most direct way for parameterize some sequence of actions (for later reuse) is creating a macro or a function. Both of them are allowed to perform any operation which can be written in a plain CMakeLists.txt.
I was using valgrind tool - callgrind and kcachegrind for profiling a large project and was wondering if there is a way that callgrind reports the stats from all the functions (not just the most expensive functions).
To be specific - When I visualized the callgraph in kcachegrind, it included only those functions that are quite expensive, but I was wondering if there is a way to include all the functions from the project in the callgraph. Command used for generating profiling info is given below :
valgrind --dsymutil=yes --tool=callgrind $EXE
I am not sure if I have to give any options to valgrind or may be compile the application at a different optimization. This might be something trivial but I couldn't find a solution. Any pointers regarding this highly appreciated.
Thanks !
It occurred to me yesterday. As shown in the picture, I found in call graph of kcachegrind, there is a right click menu, in which you can set up the threshold above which the node will be visualized.
There is also a option "no minimum", however it can not be chosen. I think maybe it's because, if every function, no matter how trivial it is, takes up a node, the graph may be too large to handle.
I just found that the script gprof2dot can handle this.
The script can convert the output of callgrind to dot, which can be visualized as graph. The script has two relevant parameters:
-n PERCENTAGE, --node-thres=PERCENTAGE to eliminate nodes below this threshold [default: 0.5]. In order to visualize all nodes in the graph, you can set the parameter like -n0
-e PERCENTAGE, --edge-thres=PERCENTAGEto eliminate edges below this threshold [default: 0.1]. In order to visualize all edges in the graph, you can set the parameter like -e0
In order to generate the complete call graph you would use both of the options (-n0 and -e0).
I've tried this, however, as the graph generated is too large, the dot software warned me that "graph is too large for cairo-renderer bitmaps. Scaling by 0.328976 to fit. " But you can set up the output format as eps which can handle this. You also can change the parameter to adapt your objective.
Example
Let's say that you have a callgrind output file called callgrind.out.1992. To generate a complete call graph you would use:
gprof2dot.py -n0 -e0 ./callgrind.out.1992 -f callgrind
To generate a PNG output image of the graph, you could run the following commands:
gprof2dot -n0 -e0 ./callgrind.out.1992 -f callgrind > out.dot
dot -Tpng out.dot -o out.png
Now you have an out.png image with the full graph.
Note the usage of the -f parameter to specify the profile format (callgrind in our case).
The command I am using is
valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes $EXE and as far as I have seen it includes all the functions in the call graph.
Hope it helps.
I'm going to complete rengar's answer with information that will allow you to generate the complete call graph, as well as give an example of the full process.
You can use the gprof2dot to show all functions in a callgraph. The script can convert the output of callgrind to dot, which can be visualized as graph. The script has two relevant parameters:
-n PERCENTAGE, --node-thres=PERCENTAGE to eliminate nodes below this threshold [default: 0.5]. In order to visualize all nodes in the graph you should set this parameter to -n0
-e PERCENTAGE, --edge-thres=PERCENTAGEto eliminate edges below this threshold [default: 0.1]. In order to visualize all edges in the graph you should set this parameter to -e0
In order to generate the complete call graph you would use both of the options: -n0 and -e0.
Example
Let's say that you have a callgrind output file called callgrind.out.1992. To generate a complete call graph you would use:
gprof2dot -n0 -e0 ./callgrind.out.1992 -f callgrind
To generate a PNG output image of the graph, you could run the following commands:
gprof2dot -n0 -e0 ./callgrind.out.1992 -f callgrind > out.dot
dot -Tpng out.dot -o out.png
Now you have an out.png image with the full graph.
Note the usage of the -f parameter to specify the profile format (callgrind in our case).
I am migrating a project from autotools to cmake. I have a question about gettext support.
There is an existing FindGettext.cmake modules that provides a nice function :
GETTEXT_CREATE_TRANSLATIONS(foo.pot ALL fr.po de.po)
where you provide a pot file and translated po fil ; the function takes care of turning the po files into gmo files, and add the proper installation targets to make sure the files can be found at runtime. All good and well.
Now comes the question : how do you update your pot files and you po files when you add new messages ?
For this, autotools would generate a "update-po" target, that (from what I understand), reads a POTFILES.in with the lists of all files containing translated strings, mixes it with other info, and ends up calling xgetext to generate the po. I think the coresponding Makefile task is the one that contains something like :
case `$(XGETTEXT) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
'' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].* | 0.16 | 0.16.[0-1]*) \
$(XGETTEXT) --default-domain=$(DOMAIN) --directory=$(top_srcdir) \
--add-comments=TRANSLATORS: $(XGETTEXT_OPTIONS) \
--files-from=$(srcdir)/POTFILES.in \
--copyright-holder='$(COPYRIGHT_HOLDER)' \
--msgid-bugs-address="$$msgid_bugs_address" \
;; \
*) \
$(XGETTEXT) --default-domain=$(DOMAIN) --directory=$(top_srcdir) \
--add-comments=TRANSLATORS: $(XGETTEXT_OPTIONS) \
--files-from=$(srcdir)/POTFILES.in \
--copyright-holder='$(COPYRIGHT_HOLDER)' \
--package-name="$${package_gnu}ube" \
--package-version='0.4.0-dev' \
--msgid-bugs-address="$$msgid_bugs_address" \
;; \
esac
So, before I reinvent the wheel, is there an existing cmake function to do the same thing ?
Or do I have to find the xgettext executable, lists the files, and do this by hand ? THe makefile version seems quite complicated (although it seems to handle lots of cases) ; I would not mind not having to write the cmake equivalent ;)
Thanks
PH
Don't let the autotool bloat scare you. :-)
You can use the following code:
SET(_potFile ${PROJECT_NAME}.pot)
ADD_CUSTOM_COMMAND(OUTPUT ${_potFile}
COMMAND ${XGETTEXT_CMD} ${_xgettext_option_list} -o ${_potFile} ${_src_list}
DEPENDS ${_src_list}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT "Extract translatable messages to ${_potFile}"
)
ADD_CUSTOM_TARGET(pot_file ${_all}
DEPENDS ${_potFile}
)
For C programs, I am using following as _xgettext_option_list
--language=C --keyword=_ --keyword=N_ --keyword=C_:1c,2 --keyword=NC_:1c,2 -s
--package-name=${PROJECT_NAME} --package-version=${PRJ_VER}
I did reinvented the wheel when the FindGettext did not have the option ALL (when it was cmake-2.4) :-)
According to this kde wiki page, using cmake for editing sources is not a good idea. Better use standalone script for updating translations.
In fact, the extraction and merging of messages does not map well onto the CMake concept of out-of-source builds, and CMake can't
provide too much help for this step, either.
Hence, in this tutorial, we will handle the first step with a
standalone shell script, and only the second step will be handled by
CMake.