fileio_read_stralloc you have reimplemented for gdbserver; I have rather
chosen to generalize the gdb/ variant and call the same common/ code from both
gdb and gdbserver. One may ask whether it is not more complicated than its
reimplementation, not sure.
By moving linux_find_memory_regions_full you have dropped make_cleanup there.
Its use from GDB may now leak memory as its called FUNC may throw an
exception. I have put there 'void **memory_to_free_ptr' to make it reusable
from both gdb and gdbserver.
I tried to make the patches similar to your code so that one can diff the
result against your patch.
There were many code formatting little changes and also needless casts
(probably from C++).
For the last [draft patch 6/6] - things not done there yet:
get_dynamic already parses/scans PHDRs, you introduce new PHDR parser, they
should be merged.
get_hex_build_id must not be based on soname, moreover playing with realname
on it, it is too fragile. It should be based on addresses, you know that l_ld
is absolute address inside the library. So find maps/smaps entry containing
l_ld, subtract its file offset from vaddr and you have the ELF header address.
Do not run get_hex_build_id quadratically - currently for each library you
open and scan maps/smaps again. Probably the best approach is to scan all
l_ld addresses from r_debug first, then qsort them and then linearly match
them to the maps/smaps entries. I am not sure but I guess they still should
be returned to GDB in their original order from r_debug for some backward and
solib-svr4.c compatibility. Also Gary Benson is working on incremental shlib
transfers from gdbserver so that it does not clash too much (it will anyway).
While just quadratic computation would be in real world acceptable all the
open/read/close syscalls I find really needlessly expensive.
On Fri, 22 Feb 2013 16:06:44 +0100, Aleksandar Ristovski wrote:
As per Jan's request, this patch adds 'build-id' to the gdbserver
response. The value is hex encoded string representing
.note.gnu.build-id section of the corresponding shared library.
gdbserver reports PT_NOTE segment, not any section. gdbserver is dependent on
runtime information (segments), it cannot rely on debug/link information
(sections).