This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Symbol file scope?
- From: Andrei Warkentin <andreiw at motorola dot com>
- To: gdb-patches at sourceware dot org
- Date: Fri, 27 May 2011 18:14:06 -0500
- Subject: Symbol file scope?
Hi,
This is my first time posting on a GDB mailing list, so excuse me in
advance if this has been covered before...
I am using GDB to debug TianoCore UEFI firmware
(http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome)
running in a virtual machine using an ICE-like gdb remote stub (gdbsx
for Xen, or just QEMU gdb support). UEFI consists of a number of
separate modules - UEFI core, various drivers and UEFI application
(not applications, just one, like the EFI shell or a bootloader). All
of these modules live in the
same indentity-mapped address space, and interact with each other via
"protocols", which are effectively just function dispatch tables
published with the UEFI core. There is no concept of "processes", a
backtrace weaves through many modulules (i.e. EFI shell called into
Core, which called into fs driver, etc).
The problem is globals. GDB expects globals to be unique, since it
thinks it is debugging a program. Global search is done is "first
fit". So it will start with the symtabs in the first object file that
was "add-symbol-file"d and return in. It would be nice to be able to
have globals be searched for first in the object file to which the
current scope is in. Additionally, it would be nice to be able to
implement "module scope" in the same fashion as "file scope", so you
can look at globals in any module like this -
(gdb) print &'DxeCore.dll'::gST
$15 = (EFI_SYSTEM_TABLE **) 0x17fca6f0
(gdb) print &'IsaBusDxe.dll'::gST
$16 = (EFI_SYSTEM_TABLE **) 0x17e21da4
I have a patch for 7.1 (I know...old) that I put together that basically -
1) Modifies lookup_symbol_global to use
lookup_global_symbol_from_objfile before lookup_symbol_aux_symatbs or
solib_global_lookup
2) Modifies lookup_symtab to match symbol object file as well. It
returns the first symtab, which is good enough for
lookup_symbol_global logic to work. (I basically wanted to avoid
modifying c-exp, p-exp, etc, parsers)
3) Fixes location completion to match object file names as well.
4) Adds a list-symbol-files command to list all objfiles and their
locations, or list only those that match objfile/source file names.
I.e -
gdb) list-symbol-files DiskIo.c Dispatcher.c EhciDxe.dll
DiskIo.c:
/home/fjnh84/mine/edk2/Build/OvmfIa32/DEBUG_GCC44/IA32/MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe/DEBUG/DiskIoDxe.dll
.text, [0x17e4c240-0x17e4f440)
Dispatcher.c:
/home/fjnh84/mine/edk2/Build/OvmfIa32/DEBUG_GCC44/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
.text, [0x17fb1240-0x17fcb8c0)
EhciDxe.dll:
/home/fjnh84/mine/edk2/Build/OvmfIa32/DEBUG_GCC44/IA32/MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe/DEBUG/EhciDxe.dll
.text, [0x17deb240-0x17df3920)
I have a patch here -
https://github.com/andreiw/andreiw-wip/blob/master/gdb/0001-GDB-Initial-prototype-of-symbol-file-scope-module-sc.patch
I realize I need to rebase it on latest gdb. I wanted to get the GDB
folks' feedback before I did anything else with this :-).
Thank you for your time,
A