* DW_FORM_ref_addr dosn't work
@ 2003-07-30 21:42 H. J. Lu
2003-07-30 21:45 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: H. J. Lu @ 2003-07-30 21:42 UTC (permalink / raw)
To: GDB
DW_FORM_ref_addr can reference an entry in a different compilation
unit, even from a different shared object. But die_ref_table only
contains DIEs in one single compilation unit. Why do we do that? What
is the best way to fix it?
BTW, I am enclosing my quick dirty hack for reference.
H.J.
----
--- dwarf2read.c.ref 2003-07-30 09:43:51.000000000 -0700
+++ dwarf2read.c 2003-07-30 14:41:24.000000000 -0700
@@ -1195,6 +1195,7 @@ dwarf2_build_psymtabs_hard (struct objfi
struct partial_symtab *pst;
struct cleanup *back_to;
CORE_ADDR lowpc, highpc;
+ struct die_info *dies;
info_ptr = dwarf_info_buffer;
abbrev_ptr = dwarf_abbrev_buffer;
@@ -1280,6 +1281,8 @@ dwarf2_build_psymtabs_hard (struct objfi
dwarf2_read_abbrevs (abfd, &cu_header);
make_cleanup (dwarf2_empty_abbrev_table, cu_header.dwarf2_abbrevs);
+ dies = read_comp_unit (info_ptr, abfd, &cu_header);
+
/* Read the compilation unit die */
info_ptr = read_partial_die (&comp_unit_die, abfd, info_ptr,
&cu_header);
@@ -3654,9 +3657,11 @@ read_comp_unit (char *info_ptr, bfd *abf
char *cur_ptr;
int nesting_level;
+#if 0
/* Reset die reference table; we are
building new ones now. */
dwarf2_empty_hash_tables ();
+#endif
cur_ptr = info_ptr;
nesting_level = 0;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: DW_FORM_ref_addr dosn't work
2003-07-30 21:42 DW_FORM_ref_addr dosn't work H. J. Lu
@ 2003-07-30 21:45 ` Daniel Jacobowitz
2003-07-30 21:52 ` H. J. Lu
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-07-30 21:45 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Wed, Jul 30, 2003 at 02:42:52PM -0700, H. J. Lu wrote:
> DW_FORM_ref_addr can reference an entry in a different compilation
> unit, even from a different shared object. But die_ref_table only
> contains DIEs in one single compilation unit. Why do we do that? What
> is the best way to fix it?
>
> BTW, I am enclosing my quick dirty hack for reference.
Please read any of the thirty-some discussions of this in the list
archives.
I'm working on it in my spare time, of which I have not had enough to
make much progress. The DWARF reader needs to be essentially
rewritten.
>
>
> H.J.
> ----
> --- dwarf2read.c.ref 2003-07-30 09:43:51.000000000 -0700
> +++ dwarf2read.c 2003-07-30 14:41:24.000000000 -0700
> @@ -1195,6 +1195,7 @@ dwarf2_build_psymtabs_hard (struct objfi
> struct partial_symtab *pst;
> struct cleanup *back_to;
> CORE_ADDR lowpc, highpc;
> + struct die_info *dies;
>
> info_ptr = dwarf_info_buffer;
> abbrev_ptr = dwarf_abbrev_buffer;
> @@ -1280,6 +1281,8 @@ dwarf2_build_psymtabs_hard (struct objfi
> dwarf2_read_abbrevs (abfd, &cu_header);
> make_cleanup (dwarf2_empty_abbrev_table, cu_header.dwarf2_abbrevs);
>
> + dies = read_comp_unit (info_ptr, abfd, &cu_header);
> +
> /* Read the compilation unit die */
> info_ptr = read_partial_die (&comp_unit_die, abfd, info_ptr,
> &cu_header);
> @@ -3654,9 +3657,11 @@ read_comp_unit (char *info_ptr, bfd *abf
> char *cur_ptr;
> int nesting_level;
>
> +#if 0
> /* Reset die reference table; we are
> building new ones now. */
> dwarf2_empty_hash_tables ();
> +#endif
>
> cur_ptr = info_ptr;
> nesting_level = 0;
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: DW_FORM_ref_addr dosn't work
2003-07-30 21:45 ` Daniel Jacobowitz
@ 2003-07-30 21:52 ` H. J. Lu
2003-07-30 21:55 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: H. J. Lu @ 2003-07-30 21:52 UTC (permalink / raw)
To: GDB
On Wed, Jul 30, 2003 at 05:45:03PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jul 30, 2003 at 02:42:52PM -0700, H. J. Lu wrote:
> > DW_FORM_ref_addr can reference an entry in a different compilation
> > unit, even from a different shared object. But die_ref_table only
> > contains DIEs in one single compilation unit. Why do we do that? What
> > is the best way to fix it?
> >
> > BTW, I am enclosing my quick dirty hack for reference.
>
> Please read any of the thirty-some discussions of this in the list
> archives.
>
> I'm working on it in my spare time, of which I have not had enough to
> make much progress. The DWARF reader needs to be essentially
> rewritten.
While waiting for your new DWARF reader, I will see how my hack
goes :-(.
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: DW_FORM_ref_addr dosn't work
2003-07-30 21:52 ` H. J. Lu
@ 2003-07-30 21:55 ` Daniel Jacobowitz
2003-07-30 22:01 ` H. J. Lu
2003-07-31 5:16 ` H. J. Lu
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-07-30 21:55 UTC (permalink / raw)
To: GDB
On Wed, Jul 30, 2003 at 02:52:27PM -0700, H. J. Lu wrote:
> On Wed, Jul 30, 2003 at 05:45:03PM -0400, Daniel Jacobowitz wrote:
> > On Wed, Jul 30, 2003 at 02:42:52PM -0700, H. J. Lu wrote:
> > > DW_FORM_ref_addr can reference an entry in a different compilation
> > > unit, even from a different shared object. But die_ref_table only
> > > contains DIEs in one single compilation unit. Why do we do that? What
> > > is the best way to fix it?
> > >
> > > BTW, I am enclosing my quick dirty hack for reference.
> >
> > Please read any of the thirty-some discussions of this in the list
> > archives.
> >
> > I'm working on it in my spare time, of which I have not had enough to
> > make much progress. The DWARF reader needs to be essentially
> > rewritten.
>
> While waiting for your new DWARF reader, I will see how my hack
> goes :-(.
Since the die table is hashed by offset (isn't it?), presumably very
badly.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: DW_FORM_ref_addr dosn't work
2003-07-30 21:55 ` Daniel Jacobowitz
@ 2003-07-30 22:01 ` H. J. Lu
2003-07-31 5:16 ` H. J. Lu
1 sibling, 0 replies; 11+ messages in thread
From: H. J. Lu @ 2003-07-30 22:01 UTC (permalink / raw)
To: GDB
On Wed, Jul 30, 2003 at 05:55:09PM -0400, Daniel Jacobowitz wrote:
> >
> > While waiting for your new DWARF reader, I will see how my hack
> > goes :-(.
>
> Since the die table is hashed by offset (isn't it?), presumably very
> badly.
>
In my case, all DIEs come from the same section.
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: DW_FORM_ref_addr dosn't work
2003-07-30 21:55 ` Daniel Jacobowitz
2003-07-30 22:01 ` H. J. Lu
@ 2003-07-31 5:16 ` H. J. Lu
2003-07-31 16:16 ` A hack for DW_FORM_ref_addr H. J. Lu
1 sibling, 1 reply; 11+ messages in thread
From: H. J. Lu @ 2003-07-31 5:16 UTC (permalink / raw)
To: GDB
On Wed, Jul 30, 2003 at 05:55:09PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jul 30, 2003 at 02:52:27PM -0700, H. J. Lu wrote:
> > On Wed, Jul 30, 2003 at 05:45:03PM -0400, Daniel Jacobowitz wrote:
> > > On Wed, Jul 30, 2003 at 02:42:52PM -0700, H. J. Lu wrote:
> > > > DW_FORM_ref_addr can reference an entry in a different compilation
> > > > unit, even from a different shared object. But die_ref_table only
> > > > contains DIEs in one single compilation unit. Why do we do that? What
> > > > is the best way to fix it?
> > > >
> > > > BTW, I am enclosing my quick dirty hack for reference.
> > >
> > > Please read any of the thirty-some discussions of this in the list
> > > archives.
> > >
> > > I'm working on it in my spare time, of which I have not had enough to
> > > make much progress. The DWARF reader needs to be essentially
> > > rewritten.
> >
> > While waiting for your new DWARF reader, I will see how my hack
> > goes :-(.
>
> Since the die table is hashed by offset (isn't it?), presumably very
> badly.
It is OK for different compilation units within the same .debug_info
section.
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* A hack for DW_FORM_ref_addr
2003-07-31 5:16 ` H. J. Lu
@ 2003-07-31 16:16 ` H. J. Lu
2003-07-31 18:22 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: H. J. Lu @ 2003-07-31 16:16 UTC (permalink / raw)
To: GDB
On Wed, Jul 30, 2003 at 10:16:53PM -0700, H. J. Lu wrote:
> > >
> > > While waiting for your new DWARF reader, I will see how my hack
> > > goes :-(.
> >
> > Since the die table is hashed by offset (isn't it?), presumably very
> > badly.
>
> It is OK for different compilation units within the same .debug_info
> section.
>
>
FYI, this is the hack I am going to try.
H.J.
----
2003-07-31 H.J. Lu <hongjiu.lu@intel.com>
* dwarf2read.c (dwarf2_build_psymtabs_hard): Read in all
compilation units.
(read_comp_unit): Don't reset die reference table if abfd
is not changed.
--- gdb/dwarf2read.c.ref 2003-07-30 09:43:51.000000000 -0700
+++ gdb/dwarf2read.c 2003-07-31 08:11:23.000000000 -0700
@@ -1195,6 +1195,7 @@ dwarf2_build_psymtabs_hard (struct objfi
struct partial_symtab *pst;
struct cleanup *back_to;
CORE_ADDR lowpc, highpc;
+ struct die_info *dies;
info_ptr = dwarf_info_buffer;
abbrev_ptr = dwarf_abbrev_buffer;
@@ -1280,6 +1281,8 @@ dwarf2_build_psymtabs_hard (struct objfi
dwarf2_read_abbrevs (abfd, &cu_header);
make_cleanup (dwarf2_empty_abbrev_table, cu_header.dwarf2_abbrevs);
+ dies = read_comp_unit (info_ptr, abfd, &cu_header);
+
/* Read the compilation unit die */
info_ptr = read_partial_die (&comp_unit_die, abfd, info_ptr,
&cu_header);
@@ -3653,10 +3656,17 @@ read_comp_unit (char *info_ptr, bfd *abf
struct die_info *first_die, *last_die, *die;
char *cur_ptr;
int nesting_level;
+ static bfd *bfd_die_ref_table;
+
+ if (!bfd_die_ref_table)
+ bfd_die_ref_table = abfd;
- /* Reset die reference table; we are
- building new ones now. */
- dwarf2_empty_hash_tables ();
+ if (bfd_die_ref_table != abfd)
+ {
+ bfd_die_ref_table = abfd;
+ /* Reset die reference table; we are building new ones now. */
+ dwarf2_empty_hash_tables ();
+ }
cur_ptr = info_ptr;
nesting_level = 0;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A hack for DW_FORM_ref_addr
2003-07-31 16:16 ` A hack for DW_FORM_ref_addr H. J. Lu
@ 2003-07-31 18:22 ` Daniel Jacobowitz
2003-07-31 18:29 ` H. J. Lu
2003-07-31 21:21 ` H. J. Lu
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 18:22 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, Jul 31, 2003 at 09:16:19AM -0700, H. J. Lu wrote:
> On Wed, Jul 30, 2003 at 10:16:53PM -0700, H. J. Lu wrote:
> > > >
> > > > While waiting for your new DWARF reader, I will see how my hack
> > > > goes :-(.
> > >
> > > Since the die table is hashed by offset (isn't it?), presumably very
> > > badly.
> >
> > It is OK for different compilation units within the same .debug_info
> > section.
> >
> >
>
> FYI, this is the hack I am going to try.
It may be safe, but it's unacceptable. Take a look at the memory usage
requirements for -readnow, if libc.so.6 has debugging information.
You've just eaten probably 200MB of RAM.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A hack for DW_FORM_ref_addr
2003-07-31 18:22 ` Daniel Jacobowitz
@ 2003-07-31 18:29 ` H. J. Lu
2003-07-31 22:33 ` Daniel Berlin
2003-07-31 21:21 ` H. J. Lu
1 sibling, 1 reply; 11+ messages in thread
From: H. J. Lu @ 2003-07-31 18:29 UTC (permalink / raw)
To: GDB
On Thu, Jul 31, 2003 at 02:22:19PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 31, 2003 at 09:16:19AM -0700, H. J. Lu wrote:
> > On Wed, Jul 30, 2003 at 10:16:53PM -0700, H. J. Lu wrote:
> > > > >
> > > > > While waiting for your new DWARF reader, I will see how my hack
> > > > > goes :-(.
> > > >
> > > > Since the die table is hashed by offset (isn't it?), presumably very
> > > > badly.
> > >
> > > It is OK for different compilation units within the same .debug_info
> > > section.
> > >
> > >
> >
> > FYI, this is the hack I am going to try.
>
> It may be safe, but it's unacceptable. Take a look at the memory usage
> requirements for -readnow, if libc.so.6 has debugging information.
> You've just eaten probably 200MB of RAM.
>
Since DW_FORM_ref_addr requires it, I don't see there is an easy way
out. I guess I could only save those used by DW_FORM_ref_addr.
H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A hack for DW_FORM_ref_addr
2003-07-31 18:22 ` Daniel Jacobowitz
2003-07-31 18:29 ` H. J. Lu
@ 2003-07-31 21:21 ` H. J. Lu
1 sibling, 0 replies; 11+ messages in thread
From: H. J. Lu @ 2003-07-31 21:21 UTC (permalink / raw)
To: GDB
On Thu, Jul 31, 2003 at 02:22:19PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 31, 2003 at 09:16:19AM -0700, H. J. Lu wrote:
> > On Wed, Jul 30, 2003 at 10:16:53PM -0700, H. J. Lu wrote:
> > > > >
> > > > > While waiting for your new DWARF reader, I will see how my hack
> > > > > goes :-(.
> > > >
> > > > Since the die table is hashed by offset (isn't it?), presumably very
> > > > badly.
> > >
> > > It is OK for different compilation units within the same .debug_info
> > > section.
> > >
> > >
> >
> > FYI, this is the hack I am going to try.
>
> It may be safe, but it's unacceptable. Take a look at the memory usage
> requirements for -readnow, if libc.so.6 has debugging information.
> You've just eaten probably 200MB of RAM.
>
FYI, this is my updated hack.
H.J.
---
2003-07-31 H.J. Lu <hongjiu.lu@intel.com>
* dwarf2read.c (die_info_list): New structure.
(need_preserve_die_ref_table): New.
(dwarf2_build_psymtabs_hard): Read in all compilation units.
Free die list die reference table is not needed.
(read_comp_unit): Reset die reference table if it is not needed
or abfd is changed
(read_attribute_value): Set need_preserve_die_ref_table to 1
for DW_FORM_ref_addr.
--- gdb/dwarf2read.c.ref_addr 2003-07-31 12:59:31.000000000 -0700
+++ gdb/dwarf2read.c 2003-07-31 14:03:10.000000000 -0700
@@ -325,6 +325,12 @@ struct die_info
struct type *type; /* Cached type information */
};
+struct die_info_list
+{
+ struct die_info *dies;
+ struct die_info_list *next;
+};
+
/* Attributes have a name and a value */
struct attribute
{
@@ -376,6 +382,7 @@ struct dwarf_block
#endif
static struct die_info *die_ref_table[REF_HASH_SIZE];
+static int need_preserve_die_ref_table = -1;
/* Obstack for allocating temporary storage used during symbol reading. */
static struct obstack dwarf2_tmp_obstack;
@@ -1195,6 +1202,8 @@ dwarf2_build_psymtabs_hard (struct objfi
struct partial_symtab *pst;
struct cleanup *back_to;
CORE_ADDR lowpc, highpc;
+ struct die_info *dies;
+ struct die_info_list *dies_list_head, *dies_list_p;
info_ptr = dwarf_info_buffer;
abbrev_ptr = dwarf_abbrev_buffer;
@@ -1230,6 +1239,13 @@ dwarf2_build_psymtabs_hard (struct objfi
obstack_init (&dwarf2_tmp_obstack);
back_to = make_cleanup (dwarf2_free_tmp_obstack, NULL);
+ need_preserve_die_ref_table = -1;
+ dies_list_head
+ = (struct die_info_list *) xmalloc (sizeof (struct die_info_list));
+ dies_list_head->dies = NULL;
+ dies_list_head->next = NULL;
+ dies_list_p = dies_list_head;
+
/* Since the objects we're extracting from dwarf_info_buffer vary in
length, only the individual functions to extract them (like
read_comp_unit_head and read_partial_die) can really know whether
@@ -1280,6 +1296,18 @@ dwarf2_build_psymtabs_hard (struct objfi
dwarf2_read_abbrevs (abfd, &cu_header);
make_cleanup (dwarf2_empty_abbrev_table, cu_header.dwarf2_abbrevs);
+ dies = read_comp_unit (info_ptr, abfd, &cu_header);
+ if (dies_list_p->dies != NULL)
+ {
+ struct die_info_list *p = (struct die_info_list *)
+ xmalloc (sizeof (struct die_info_list));
+
+ p->next = NULL;
+ dies_list_p->next = p;
+ dies_list_p = p;
+ }
+ dies_list_p->dies = dies;
+
/* Read the compilation unit die */
info_ptr = read_partial_die (&comp_unit_die, abfd, info_ptr,
&cu_header);
@@ -1349,6 +1377,22 @@ dwarf2_build_psymtabs_hard (struct objfi
info_ptr = beg_of_comp_unit + cu_header.length
+ cu_header.initial_length_size;
}
+
+ if (need_preserve_die_ref_table != 1)
+ {
+ struct die_info_list *next;
+
+ for (dies_list_p = dies_list_head; dies_list_p != NULL;
+ dies_list_p = next)
+ {
+ next = dies_list_p->next;
+ make_cleanup_free_die_list (dies_list_p->dies);
+ free (dies_list_p);
+ }
+
+ need_preserve_die_ref_table = 0;
+ }
+
do_cleanups (back_to);
}
@@ -3653,10 +3697,18 @@ read_comp_unit (char *info_ptr, bfd *abf
struct die_info *first_die, *last_die, *die;
char *cur_ptr;
int nesting_level;
+ static bfd *bfd_die_ref_table;
- /* Reset die reference table; we are
- building new ones now. */
- dwarf2_empty_hash_tables ();
+ if (!bfd_die_ref_table)
+ bfd_die_ref_table = abfd;
+
+ if (need_preserve_die_ref_table == 0
+ || bfd_die_ref_table != abfd)
+ {
+ bfd_die_ref_table = abfd;
+ /* Reset die reference table; we are building new ones now. */
+ dwarf2_empty_hash_tables ();
+ }
cur_ptr = info_ptr;
nesting_level = 0;
@@ -4080,8 +4132,9 @@ read_attribute_value (struct attribute *
attr->form = form;
switch (form)
{
- case DW_FORM_addr:
case DW_FORM_ref_addr:
+ need_preserve_die_ref_table = 1;
+ case DW_FORM_addr:
DW_ADDR (attr) = read_address (abfd, info_ptr, cu_header, &bytes_read);
info_ptr += bytes_read;
break;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: A hack for DW_FORM_ref_addr
2003-07-31 18:29 ` H. J. Lu
@ 2003-07-31 22:33 ` Daniel Berlin
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Berlin @ 2003-07-31 22:33 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
>
> Since DW_FORM_ref_addr requires it, I don't see there is an easy way
> out. I guess I could only save those used by DW_FORM_ref_addr.
>
Back when this support was implemented the first (or was it the second)
time, I just had it keep around the last 5 or 10 referenced compilation
units full of dies in an LRU cache, and just reread non-cached CU's as
necessary.
I think Daniel planned on doing something similar for the third rewrite.
>
> H.J.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-07-31 22:33 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-30 21:42 DW_FORM_ref_addr dosn't work H. J. Lu
2003-07-30 21:45 ` Daniel Jacobowitz
2003-07-30 21:52 ` H. J. Lu
2003-07-30 21:55 ` Daniel Jacobowitz
2003-07-30 22:01 ` H. J. Lu
2003-07-31 5:16 ` H. J. Lu
2003-07-31 16:16 ` A hack for DW_FORM_ref_addr H. J. Lu
2003-07-31 18:22 ` Daniel Jacobowitz
2003-07-31 18:29 ` H. J. Lu
2003-07-31 22:33 ` Daniel Berlin
2003-07-31 21:21 ` H. J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).