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

[Taimoor <tmirza@codesourcery.com>]

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