aboutsummaryrefslogtreecommitdiff
path: root/gdb/objfiles.c
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@gnat.com>2011-12-21 07:11:52 +0000
committerJoel Brobecker <brobecker@gnat.com>2011-12-21 07:11:52 +0000
commit50f8ea949d73101ef1dc3d68dfbb7e5e35d4e82a (patch)
treefa8f9597284f6b52512ccc7553280c047eb349e6 /gdb/objfiles.c
parent9ac7f98e7cc67d360b5aab46f281440b6b446288 (diff)
downloadgdb-50f8ea949d73101ef1dc3d68dfbb7e5e35d4e82a.zip
gdb-50f8ea949d73101ef1dc3d68dfbb7e5e35d4e82a.tar.gz
gdb-50f8ea949d73101ef1dc3d68dfbb7e5e35d4e82a.tar.bz2
missing check against overlay_debugging in objfiles.c
This fixes a problem where the debugger is trying to locate a minimal symbol from its address, when the symbol is inside a section whose VMA is different from its LMA. We have a program that was built on ppc-elf using a linker script such that data sections are placed in ROM, and then loaded onto RAM at execution. So their VMA addresses are indeed different from their LMA address. Unfortunately, there is one place where GDB gets slightly confused into thinking that these data sections are overlayed, while it's not the case here. This show up when trying to print the list of Ada tasks, where GDB is unable to determine their names, and thus prints a generic `Ravenscar task' instead: (gdb) info tasks ID TID P-ID Pri State Name 1 1d580 127 Delay Sleep Ravenscar task 2 183f8 127 Delay Sleep Ravenscar task * 3 13268 127 Runnable Ravenscar task We expected: (gdb) info tasks ID TID P-ID Pri State Name 1 1d580 127 Delay Sleep environment_task 2 183f8 127 Delay Sleep raven2 * 3 13268 127 Runnable raven1 The name of the task is determined by looking up the symbol table using the task ID, which is the address where the symbol is defined. So, ada-tasks calls... msym = lookup_minimal_symbol_by_pc (task_id); ... which in turn first tries to determine the section associated to this address (find_pc_section), which itself uses a map of sections to find it. The map itself is recomputed every time objfiles are loaded/changed by `update_section_map'. And `update_section_map' relies on `insert_section_p' to determine whether the section should be inserted in the map or not. This is where things get interesting for us, because `insert_section_p' simply rejects overlay sections: if (lma != 0 && lma != bfd_section_vma (abfd, section) && (bfd_get_file_flags (abfd) & BFD_IN_MEMORY) == 0) /* This is an overlay section. IN_MEMORY check is needed to avoid discarding sections from the "system supplied DSO" (aka vdso) on some Linux systems (e.g. Fedora 11). */ return 0; However, it shouldn't reject our section in this case, since overlay debugging is off. The fix is to add a check that overlay debugging is active before rejecting the section. This is similar to what is done in `section_is_overlay' (which takes obj_section objects), for instance. gdb/Changelog: * objfiles.c (insert_section_p): Do not detect overlay sections if overlay debugging is off.
Diffstat (limited to 'gdb/objfiles.c')
-rw-r--r--gdb/objfiles.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/objfiles.c b/gdb/objfiles.c
index fb26420..1cb1698 100644
--- a/gdb/objfiles.c
+++ b/gdb/objfiles.c
@@ -1117,7 +1117,7 @@ insert_section_p (const struct bfd *abfd,
{
const bfd_vma lma = bfd_section_lma (abfd, section);
- if (lma != 0 && lma != bfd_section_vma (abfd, section)
+ if (overlay_debugging && lma != 0 && lma != bfd_section_vma (abfd, section)
&& (bfd_get_file_flags (abfd) & BFD_IN_MEMORY) == 0)
/* This is an overlay section. IN_MEMORY check is needed to avoid
discarding sections from the "system supplied DSO" (aka vdso)