Closed lks9 closed 1 year ago
i can't continue with the #3 because of the dependency so i'll try to do this. how should we structure the database? Is just 1 table for the hex_list enough?
Sorry for keeping quiet so long. Yes one table with num
, file
, line
, name
should be enough to start.
1) The num
should be a unique key.
2) We also need to lookup the num
from file
+ line
+ name
. But for that we don't need a separate table.
3) (optional) In the json there is also pre_file
plus offset
. This can be a useful info for manual look-up. Since one num
can have multiple pre_file
s, this should be saved to a separete table with num
, pre_file
, offset
. In that table, the combination pre_file
plus offset
would be unique.
i don't quite get why one num
can have multiple pre_file
? And also should i normalize it to 3NF?
If you compile
foo.c
(including somelib.h
)
bar.c
(including somelib.h
)
and somelib.h
contains some function definition, say
static inline int h(void) {
return 0;
}
then you get the h
function both in the pre-processed foo.i
and in bar.i
with different offsets. However, the file
would still correspond to somelib.h
with line
inside somelib.h
. And the num
should be for both function copies in foo.i
and bar.i
the same.
3NF normalization: I think the result should be 2 tables if the optional part with num
, pre_file
and offset
is takes a separate table.
Thank you very much, it got already merged!
I made two change suggestions in the pull request. So I leave this issue open until they are dealed with.
This should be more stable and more performant than the current way. Needs some work in
instrumenter.py
andretrace.py
. There is a nice tutorial on databases with python here: https://vegibit.com/how-to-use-a-database-in-python/The easiest option would be a sqlite database (which is also just a file). Then we need to have some argument/paramater for the instrumenter and retrace if you want to specify an alternate location for the database file.
Requires:
8