Joel Brobecker
50f8ea949d
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.