Copied the fallback code from cmd_debug.c:r_debug_get_baddr().
getBaddrFromDebugger() from radare2.c also does the right thing. r_debug_get_baddr() probably should be exposed through the api so everyone can use one, maybe correct, version.
When opening a binary with -nn internal structures are not initialized being
one of them RBinFile that is need to retrieve the info.
However, when opening an image for example RBinFile exist but we do not have a
corresponding plugin or binary format to say so we are able to get strings.
This will be need a great refactor to handle correctly and furthermore
something I did not like is that baddr is only accesible through RBinObject and
I think it should be within RBin at least.
This was working before cause rabin2 was being called but without -B as
parameter. I have resorted for eprintf message so the user can configure as his
need.
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.
correct the add section check
keep commented part to it's original code
int to ut64
minor fix and limit buffer size in case file size cannot be allocted
remove section check
show size in readable format
minor changes
