Re: Improving GDB's mechanism to check if function is GC'ed

Taimoor
2015-06-10T12:04:26Z

On 06/10/2015 03:17 PM, Pedro Alves wrote:
> Hmm, does it really need to, though? We expose mechanisms like
> add-symbol-file, xml library list with qXfer:libraries:read (the default
> solib provider), xml target descriptions, "info os", etc., exactly so
> that GDB doesn't have to learn about the myriad of random RTOS's out there.
>
> That said, I don't really understand the patch. How can you have
> real code at address 0, but then_not_ have address 0 covered
> by a section?

This code is a relocatable object that is dynamically loaded by dynamic
loader that is part of loaded image. So you load your main kernel image
but you can load/unload relocatable objects to add further enhancements
to your main kernel image. This allows RTOS application developers to
add new features or provide bug fixes in their applications without
rebuilding and reflashing everything.

We currently use add-symbol-file for these relocatable objects. Previous
GC'ing mechanism of GDB was working fine for us as it was using flag
has_section_at_zero to determine whether
address zero in debug info means the corresponding code has been
GC'ed. But this mechanism was changed in
https://sourceware.org/ml/gdb-patches/2014-08/msg00468.html and now
functions at address 0x0 in dwarf of relocatable object are marked GC'ed
by GDB.

Thanks,
Taimoor