This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]