That is not the kind of bug I see everyday
1- calling convention db is loaded
2- function cc types is initialized by project file, that string is only
one copy across the whole database for memory efficiency.
3- The db is reloaded due to change in arch or what ever, Old strings
are freed and new one is created with totally new address. Most cases it
just reload the same database.
4- Addresses in function cc types are not updates, they are already
freed at reloading db step
Solution implemented at db reloading step:
1- create new temp db with all possible available calling conventions and
the adresses in memory of these calling conventions
2- once db is reloaded, grab adress of cc from function, match it with
the name in the new temp db, then replace it with the constant value
from the newly loaded db
* Adding types documentation
* refactoring and optimizing types databases
All based on docs
* fixing r_core_types_init
Basically we needed to try all possible 7 combinatios of file name,
I am not sure if there is a way to do that automatically.
one extra thing, since this is init subroutine we should make sure
that the db is already empty, when reloading this function
(by changing env vars), it will be reloaded thus it needs a reset first.
This was originally used to cause a seek to the next block prior to
reading such that successive calls to r_core_block_read() would progress
through memory one block at a time. This was broken, though, by commit
452669d94113 ("more cleanup in r_core_block_read") when when it used
`next' to directly calculate the offset rather than via a seek.
Only one call site remains that attempts to read the next block instead
of the current, and this probably was not even observable due to the
"hacky fix" added in commit 3bfa61946eca ("Cleaner pvj, fix tinype load,
and honor 'ao N's").
The current of semantics of `next' appear to be broken and there is very
little dependence on it. If the original behavior should be restored
anywhere, it would be much better to add a new function, or just do the
seek explicitly, rather than parameterizing r_core_block_read() on it.
