[Bernardo Hummes] buildroot

labs/sysprog/gps/Makefile

@@ -1,4 +1,4 @@
-all: init libptmx libnmea gps
+all: init libptmx libnmea libhook gps
 
 init:
 	mkdir -p bin lib include
@@ -12,13 +12,16 @@ libptmx: init
 libnmea: init
 	cd src/lib/nmea && make
 
+libhook: init
+	cd src/lib/hook && make
+
 clean:
 	find . -name *.o | xargs rm -f
 	rm -rf bin
 	rm -rf lib
 	rm -rf include
 
-ok: init libptmx libnmea_ok gps
+ok: init libptmx libnmea_ok libhook gps
 
 libnmea_ok:
 	cd src/lib/nmea && make ok

labs/sysprog/gps/run.sh

@@ -4,4 +4,5 @@ SCRIPT=`readlink -f $0`
 ROOT_DIR=`dirname $SCRIPT`
 
 export LD_LIBRARY_PATH=$ROOT_DIR/lib
+export LD_PRELOAD=$ROOT_DIR/lib/libhook.so
 $ROOT_DIR/bin/gps

labs/sysprog/gps/src/lib/hook/Makefile

@@ -0,0 +1,8 @@
+SONAME = libhook.so
+GCC = gcc
+
+all:
+	$(GCC) -g -c -fPIC hook.c -o hook.o
+	$(GCC) -g -shared -Wl,-soname,$(SONAME) -o $(SONAME) hook.o
+#	cp hook.h ../../../include
+	mv $(SONAME) ../../../lib

labs/sysprog/gps/src/lib/hook/hook.c

@@ -0,0 +1,52 @@
+#include <string.h>
+#include <stdio.h>
+#include <math.h>
+#include <time.h>
+#include <stdlib.h>
+#include <signal.h>
+
+#include <stdarg.h>
+
+#define KNOT_TO_KMH 1.852
+
+int iteration = 0;
+
+void signals_handler(int signal_number)
+{
+    printf("Signal caught and being ignored.\n");
+}
+
+int knot_to_kmh_str(float not, size_t size, char * format, char * kmh_str)
+{
+    float kmh = KNOT_TO_KMH * not;
+    snprintf(kmh_str, size, format, kmh);
+
+#ifndef GPS_OK
+    iteration++;
+    if (iteration == 2)
+    {
+        puts("working");
+    }
+#endif
+
+    return kmh;
+}
+
+int printf(const char *format, ...)
+{
+   va_list arg;
+   int done;
+
+    // signals handler
+    struct sigaction action;
+    action.sa_handler = signals_handler;
+    sigemptyset(& (action.sa_mask));
+    action.sa_flags = 0;
+    sigaction(SIGINT, & action, NULL);
+
+   va_start (arg, format);
+   done = vfprintf (stdout, format, arg);
+   va_end (arg);
+
+   return done;
+}

tps/buildroot.md

@@ -0,0 +1,36 @@
+# Partie 1: Construction d'OS avec Buildroot et chaine de cross-compilation 
+
+* Question 1: 
+  * *configs/embsys_defconfig*: It is buildroot's configuration file, with specifications of how the system is to be built, what is has access to and the tools available. There are fields in the configuration file for each of the aspects of the system being specified, using boolean or simple strings to configure.
+  * *busybox.config*: It is the configuration file use by busybox, the toolbox used to facilitate the building of embedded systems. The configuration is done via a list of flags to be enabled.
+  * *users.table*: It is a file used by buildroot to specify the basics of each user, such as their home and their default shell. Each line corresponds to a user.
+
+* Question 2: Considering that it is the 32 bits version of a raspberry 3, it should use the file *configs/raspberrypi3_defconfig*.
+
+* Question 3: The folder *package/* contains all of the packages to be made available by the system, containing the build information needed to create them, as well as the validity hashes and variables used set during the compilation. Sometimes they are grouped in subfolders when they correspond to the same category.
+
+* Question 4: The command compiles the base necessary to customize the rest of the building process, creating an initial .config file that will then be customizable trough the make menuconfig.
+
+* Question 5:
+  * Architecture: ARM little endian
+  * CPU: ARMV8
+  * ABI: EABIhf, meaning that the board has a floating point unit and it doesn't have to be emulated via software.
+  * C library: uClibc-ng
+  * Cross compiler: GCC 6.x
+  * Kernel: Custom kernel from raspberry pi's repository.
+
+* Question 6: Yes, openssh will be compiled and that can be seen in the Target packages -> Network applications section of the menuconfig. The same can be determined with the existence of the flag BR2_PACKAGE_OPENSSH=y in the configuration file.
+
+* Question 7: Busybox is a set of tools made available to make easier the development of embedded systems, aiding the with multiple packages made available withing a single binary. The make command displays the configuration interface related to busybox's available packages, allowing us to customize that is to be included when compiling the system with it.
+
+* Question 8: *output/host/* contains the generated toolchain from the cross compilation. The mentioned binary is the gcc compiler built for the targeted architecture (ARM, in the raspberry pi).
+
+* Question 9: The file was created in the src folder, inside the uncompressed tarball. The output of *file hw* is hw: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=aeb0a450fe32efb19ded5a57c8e9129c2d6b283a, not stripped. It is the specification of the contents of the file. When it is run, it displays "Hellow world!".
+
+* Question 10: When run, it displays hw: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, not stripped. It is a binary generated for a different architecture (ARM, as opposed to x86-64). This happens because it used the package generated aiming at the other architecture, as intended.
+
+* Question 11: *output/images/* contains the compiled images of the system. Examples are the one made for the sdcard (*sdcard.img*), a compressed image (*zImage*), and the initial RAM disk (*rootfs.tar*).
+
+* Question 12: zImage outputs "zImage: Linux kernel ARM boot executable zImage (little-endian)", and sdcard.img outputs "sdcard.img: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x0,0,2), end-CHS (0x4,20,17), startsector 1, 65536 sectors; partition 2 : ID=0x83, start-CHS (0x4,20,18), end-CHS (0x1d,146,54), startsector 65537, 409600 sectors". This can be understood as the first one being self contained and executable, and the second one just an image to be booted. 
+
+* Question 13: In */tmp/rootfs/* can be found the extracted root file system, which is the base system for the operating system being built. 

tps/minicom.cap

@@ -0,0 +1 @@
+$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.27,N,00748.68,E,151110,A$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.33,N,00748.74,E,151114,A$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.39,N,00748.80,E,151118,A$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.45,N,00748.86,E,151122,A$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.51,N,00748.92,E,151126,A$GPVTG,056.0,T,035.7,M,006.8,012.6,K$GPGLL,4844.57,N,00748.98,E,151130,A

tps/tp1.md

@@ -0,0 +1,11 @@
+# TP 1: System programming: part 1
+
+* Question 1: The makefile is used to specify the steps used to build a project, a make system, with the correct order and linkings between libraries, sources, etc. Make is a build tool used for the aforementioned steps, building executables. 
+
+* Question 2: The gcc compiler is used here.
+
+* Question 3: A shared library is a library that may be used by multiple executables at the same time. When linked, they are not copied into the executable, but references to the functions and their locations are specified instead.
+
+* Question 4: An example of an executable binary is the gps generated in *bin/gps*, which could be linked with something such as *gcc gps.c -o gps*
+
+* Question 5: An example of shared library is the one generated in *lib/libnmea.so*. Its creation requires some more steps, being first that the object file has to be generated with position independent code, so that the memory addresses are not overlapped by other code being used simultaneously, and can be done for example with *gcc -c -fpic nmea.c -o nmea.o*. Later, the objects have to be linked in order to create the shared library, which also has to be specified, such as with *gcc -shared libnmea.so nmea.so* (in this case only one object is linked).

tps/tp2.md

@@ -0,0 +1,44 @@
+# Compilation, debug et gestionnaire de signaux
+
+## Exercise 1: GDB et fichier core
+
+* Question 1: The process finishes with a segmentation fault and the core is dumped. It can be deduced that its end was involuntary because it accessed a memory that it did not own.
+
+* Question 2: The signal produced was SIGSEGV, as informed by gdb. It can also be seen by using *echo $?*, which will display the error 139, representing segmentation fault error.
+
+* Question 3: The problem happens at the gps code, with the usage of *nmea_vtg(&vtg)* at line 40 of the source, which triggers an error at the nmea library at line 23 with the command *puts(NULL)*, being NULL a faulty parameter for puts, as it attends a points for a string.
+
+* Question 4: It doesn't succeed in running the binary as it cannot find the shared library. If the *LD_LIBRARY_PATH* variable is fixed to point to the local *lib/* folder, then it runs the binary and crashes the same way as before, waiting for a command from the user to continue the interaction.
+
+* Question 5: The command *ldd* is used to see which shared libraries are linked, that being useful as multiple versions of a library may be installed in the same computer.
+
+* Question 6: By correcting the library being used for the commands that fail.
+
+* Question 7: The command n, short for next, executes until the next line of code in the source, as long as there are debugging annotations allowing that. The command s, short for step, does the same thing, but doesn't enter functions as they appear in the code, skipping their execution.
+
+* Question 8: Remote tools like that are useful when the code is being run a computer different from the one being used, such as in servers and robots, where there are multiple pieces of hardware to be managed.
+
+
+## Exercise 2: LD_PRELOAD et sigaction
+
+* Questions 1, 2, 3: in their source files
+
+* Question 4: It is an user command.
+
+* Question 5: The signal handler is located from the line 93 to 97 in the gps.c file. The handler is first initialized as a function that processes the signals being caught, first by displaying it, then closing the connection to the ptmx and finally exiting the process correctly. Afterwards, the set of signals is initialized with nothing (empty set), and the modifiers to the signals is also set to none (0 as the flag represents no modifiers). In the end, the sigaction function is called, changing the process to behave when receiving SIGINT signal as previously specified by the action (and the handler inside).
+
+* Question 6: In code.
+
+* Question 7: One way is to just kill the process, by finding its PID and using the kill tool, such as in *kill 88783*, or with *pkill gps*, being gps the name of the executable running. Another alternative is to suspend it with ctrl-z.
+
+* Question 8: It compiles the libnmea with GPS_OK=1, making it not execute the code in lines 20-24 in nmea.c. It works by changing a flag used inside the code during compilation.
+
+
+## Exercise 3: Terminal série (minicom) 
+
+* Question 1: Used the command *minicom -p /dev/pts/X*, being X informed when executing gps.
+
+* Question 2: The speed is how many bits per second are transmitted, the parity is used in case any is expected so to have some fault tolerance (it's set to none) and data is the number of bits of each message.
+
+* Question 3: It was used the function "Capture on/off" inside minicom.
+