As I have stated last week, Dr Shawn recommended me with two ways to retrieve addresses where LOAD or STORE operation occur and to which module it happens. I will explain the two methods briefly.
When the simulation starts, get the map of variables and addresses that we set ourselves to make sure addresses are within a specific range. Meanwhile, get the ids of components on the schematic and sort them alphabetically. Plus, the content of the map of variables and addresses is already sorted alphabetically. In this way, the first address will match the first id, and second address will match the second id and so on. Thus, when we detect a relevant component address while Load or Store operation is performed, we trigger the corresponding component by using its id from the sorted array of ids.
when we detect a relevant component address while Load or Store operation is performed, we trigger the corresponding component by using its id which is extracted from the elf file which was produced out of the compilation process.
Which method do you think is better to use? Well, method 2 is obviously much better than the first one although it is more difficult to be done. Method 2 is good because it retrieves the information from the elf file, hence, the system output will be more robust and will never be out of sync with the written code. That is why I preferred to follow the second method. There are many tools to read elf files, such as gdb, nm and readelf.
First, I preferred to use gdb to do that. However, I faced a problem while I was using gdb. The problem was that gdb could not recognize addresses that we set. As I just mentioned above, we set the addresses of the components to ensure they are within a specific range so it becomes easy for us to find them later on. Anyway, this map of addresses is linked to the elf file after the compilation process is done which might be the reason gdb cannot recognize these addresses. Dr Shawn asked me to figure out a way to include the addresses map to gdb or a way to link the map to the elf file during compilation. However, I was not able to figure out how to do that.
That is why I decided to go with the method 1 first because I did not want this problem to stop me from doing my task. Thankfully, I was able to perform the task following the first method. While I was doing it, I figured out a way to retrieve the information we need for the simulation from the kernel file without using gdb, however, instead I stored the addresses of components/modules types and names while simulation was running and before the line-by-line simulation starts. At this stage, constructors of all modules run, hence, it is possible to extract data from there.
Finally, when Dr Shawn saw my progress, he stated out an issue with the system. The issue is that I was sending an HTTP request after each line runs to retrieve the full id of modules on the back-end knowing the addresses of types and names of the modules. This may make the system too slow, especially if the user has a slow Internet connection. Thus, I edited on the code to get all ids of the modules all at once by sending only one request and then store these ids on the browser side. Finally, triggering the simulation has been done. I only make the modules blink for now. However, later on, I am going to work on performing different operations when running the simulation according to the type of the component.