[Bug gdb/25408] New: Automatic overlay debugging is not optimal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/25408] New: Automatic overlay debugging is not optimal

fweimer at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25408

            Bug ID: 25408
           Summary: Automatic overlay debugging is not optimal
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: sergey.belyashov at gmail dot com
  Target Milestone: ---

First, currently automatic overlay debugging is poorly documented. It does not
clear how many entries should have _ovly_table: number of overlays itself or
number of overlayed areas. After some investigation I found answer: worst case
for me: number of overlays.

Now I describe why it is worst.

My project have 2 overlay areas. One for code (256 overlays by 16KB) and one
for data (32 overlays by 4KB). Statically mapped RAM is very low: 8KB.

One entry of _ovly_table requires 4*4=16 bytes. So table will be 16*(256+32) =
4.5KB. It is not acceptable because it is more than a half of available RAM.

My suggestion is to add support for new approach. Where root is address space
area of the process but not overlay itself.

For example:
_ovly_areas_table:
This variable must be an array of the following structures:

struct
{
  /* The area address.  */
  unsigned long address;

  /* The area size (0 for unmapped area), in bytes.  */
  unsigned long size;

  /* The mapped overlay's load address.  */
  unsigned long lma;

  /* Mapped overlay index.  */
  unsigned long index;
}

_ovly_areas_n:
This variable must be a four-byte unsigned integer, holding the total number of
elements in _ovly_areas_table.

unsigned long _ovly_areas_n = 2;
unsigned long _ovly_table[_ovly_areas_n][4] = {
   {0x8000, 0x4000, 0x01008000, 0x0001},
   {0xE000, 0x2000, 0x02000000, 0x0001}
};
So this table says:
Overlay N1 is mapped to area 0x8000...0xBFFF from 0x01008000
Overlay N1 is mapped to area 0xE000...0xFFFF from 0x02000000

Table about existing overlays can be stored in special section of binary (or
added special section naming convention), and may not be loaded to target
system.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/25408] Automatic overlay debugging is not optimal

fweimer at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25408

--- Comment #1 from Sergey Belyashov <sergey.belyashov at gmail dot com> ---
This is comment from gdb/symfile.c:
   The overlay_update function pokes around in the target's data structures
   to see what overlays are mapped, and updates GDB's overlay mapping with
   this information.

   In this simple implementation, the target data structures are as follows:
   unsigned _novlys;            /# number of overlay sections #/
   unsigned _ovly_table[_novlys][4] = {
   {VMA, OSIZE, LMA, MAPPED},    /# one entry per overlay section #/
   {..., ...,  ..., ...},
   }
   unsigned _novly_regions;     /# number of overlay regions #/
   unsigned _ovly_region_table[_novly_regions][3] = {
   {VMA, OSIZE, MAPPED_TO_LMA},  /# one entry per overlay region #/
   {..., ...,  ...},
   }
   These functions will attempt to update GDB's mappedness state in the
   symbol section table, based on the target's mappedness state.

So my idea was already planned by Jason Molenda in 1999 but was not implemented
yet.

--
You are receiving this mail because:
You are on the CC list for the bug.