* 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: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
* 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
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).