Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/3] Check data is GC'ed
Date: Fri, 22 Aug 2014 18:02:00 -0000	[thread overview]
Message-ID: <21495.34225.60705.175416@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <1408609338-17561-2-git-send-email-yao@codesourcery.com>

Hi. Comments inline.

Yao Qi writes:
 > We see the following fail on arm-none-eabi target,
 > 
 > (gdb) print &var^M
 > $1 = (int *) 0x0 <_ftext>^M
 > (gdb) FAIL: gdb.dwarf2/dw2-var-zero-addr.exp: print &var
 > 
 > Test dw2-var-zero-addr.exp is intended to test whether GDB can
 > correctly know variable var is GC'ed by linker.  Currently, the
 > heuristic GDB is using is (see add_partial_symbol)
 > 
 >  	  && addr == 0
 > 	  && !dwarf2_per_objfile->has_section_at_zero
 > 
 > however, it doesn't work for bare metal targets, on which certain
 > section is located at address zero.  In this patch, we improve the
 > heuristic that if the variable address is zero, and section at address
 > zero is executable, we think the variable is GC'ed by linker, because
 > there can't be a variable in an executable section.  In order to know
 > this, we replace flag has_section_at_zero with a pointer
 > section_at_zero.
 > 
 > gdb:
 > 
 > 2014-08-20  Yao Qi  <yao@codesourcery.com>
 > 
 > 	* dwarf2read.c (struct dwarf2_per_objfile) <has_section_at_zero>:
 > 	Remove.
 > 	<section_at_zero>: New field.  Callers update.
 > 	(add_partial_symbol): Extend the condition to check whether the
 > 	section at zero is executable.
 > 	(new_symbol_full): Check whether the section at zero is
 > 	executable.
 > ---
 >  gdb/dwarf2read.c | 32 +++++++++++++++++++-------------
 >  1 file changed, 19 insertions(+), 13 deletions(-)
 > 
 > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
 > index cf2ce76..f5b6341 100644
 > --- a/gdb/dwarf2read.c
 > +++ b/gdb/dwarf2read.c
 > @@ -278,9 +278,8 @@ struct dwarf2_per_objfile
 >       original data was compressed using 'dwz -m'.  */
 >    struct dwz_file *dwz_file;
 >  
 > -  /* A flag indicating wether this objfile has a section loaded at a
 > -     VMA of 0.  */
 > -  int has_section_at_zero;
 > +  /* The section of this objfile loaded at a VMA of 0.  */
 > +  asection *section_at_zero;

If overlays are in use, could multiple sections be at zero?
[I think so, but I haven't used overlays in awhile.]
Storing a vector of sections_at_zero seems like massive
overkill to solve this problem, maybe there's a simpler solution,
I don't know.  But I'm not opposed to it if it's the only
solution we have at the moment.

 >  
 >    /* True if we are using the mapped index,
 >       or we are faking it for OBJF_READNOW's sake.  */
 > @@ -2186,7 +2185,7 @@ dwarf2_locate_sections (bfd *abfd, asection *sectp, void *vnames)
 >  
 >    if ((bfd_get_section_flags (abfd, sectp) & SEC_LOAD)
 >        && bfd_section_vma (abfd, sectp) == 0)
 > -    dwarf2_per_objfile->has_section_at_zero = 1;
 > +    dwarf2_per_objfile->section_at_zero = sectp;
 >  }
 >  
 >  /* A helper function that decides whether a section is empty,
 > @@ -6851,7 +6850,13 @@ add_partial_symbol (struct partial_die_info *pdi, struct dwarf2_cu *cu)
 >  
 >        if (pdi->d.locdesc
 >  	  && addr == 0
 > -	  && !dwarf2_per_objfile->has_section_at_zero)
 > +	  /* When the address is 0, if the object file doesn't have
 > +	     section at zero or the section at zero is executable,
 > +	     we think address 0 means the corresponding variable is
 > +	     removed by linker, instead of there is a data at address
 > +	     0.  */
 > +	  && (dwarf2_per_objfile->section_at_zero == NULL
 > +	      || dwarf2_per_objfile->section_at_zero->flags & SEC_CODE))

Could there be a DW_TAG_variable in SEC_CODE?
Someone might put one there for a particular reason.

 >  	{
 >  	  /* A global or static variable may also have been stripped
 >  	     out by the linker if unused, in which case its address
 > @@ -7341,8 +7346,8 @@ dwarf2_read_symtab (struct partial_symtab *self,
 >  	    = objfile_data (objfile->separate_debug_objfile_backlink,
 >  			    dwarf2_objfile_data_key);
 >  
 > -	  dwarf2_per_objfile->has_section_at_zero
 > -	    = dpo_backlink->has_section_at_zero;
 > +	  dwarf2_per_objfile->section_at_zero
 > +	    = dpo_backlink->section_at_zero;
 >  	}
 >  
 >        dwarf2_per_objfile->reading_partial_symbols = 0;
 > @@ -11758,7 +11763,7 @@ dwarf2_ranges_read (unsigned offset, CORE_ADDR *low_return,
 >        /* A not-uncommon case of bad debug info.
 >  	 Don't pollute the addrmap with bad data.  */
 >        if (range_beginning + baseaddr == 0
 > -	  && !dwarf2_per_objfile->has_section_at_zero)
 > +	  && !dwarf2_per_objfile->section_at_zero)

Convention is to write "ptr == NULL" instead of "!ptr".

 >  	{
 >  	  complaint (&symfile_complaints,
 >  		     _(".debug_ranges entry has start address of zero"
 > @@ -11871,7 +11876,7 @@ dwarf2_get_pc_bounds (struct die_info *die, CORE_ADDR *lowpc,
 >       labels are not in the output, so the relocs get a value of 0.
 >       If this is a discarded function, mark the pc bounds as invalid,
 >       so that GDB will ignore it.  */
 > -  if (low == 0 && !dwarf2_per_objfile->has_section_at_zero)
 > +  if (low == 0 && !dwarf2_per_objfile->section_at_zero)
 >      return 0;
 >  
 >    *lowpc = low;
 > @@ -12095,7 +12100,7 @@ dwarf2_record_block_ranges (struct die_info *die, struct block *block,
 >  
 >  	      /* A not-uncommon case of bad debug info.
 >  		 Don't pollute the addrmap with bad data.  */
 > -	      if (start == 0 && !dwarf2_per_objfile->has_section_at_zero)
 > +	      if (start == 0 && !dwarf2_per_objfile->section_at_zero)
 >  		{
 >  		  complaint (&symfile_complaints,
 >  			     _(".debug_ranges entry has start address of zero"
 > @@ -15668,7 +15673,7 @@ read_partial_die (const struct die_reader_specs *reader,
 >  	 labels are not in the output, so the relocs get a value of 0.
 >  	 If this is a discarded function, mark the pc bounds as invalid,
 >  	 so that GDB will ignore it.  */
 > -      if (part_die->lowpc == 0 && !dwarf2_per_objfile->has_section_at_zero)
 > +      if (part_die->lowpc == 0 && !dwarf2_per_objfile->section_at_zero)
 >  	{
 >  	  struct gdbarch *gdbarch = get_objfile_arch (objfile);
 >  
 > @@ -17297,7 +17302,7 @@ dwarf_decode_lines_1 (struct line_header *lh, const char *comp_dir,
 >  		    pst = cu->per_cu->v.psymtab;
 >  
 >  		  if (address == 0
 > -		      && (!dwarf2_per_objfile->has_section_at_zero
 > +		      && (!dwarf2_per_objfile->section_at_zero
 >  			  || (pst != NULL && pst->textlow > address)))
 >  		    {
 >  		      /* This line table is for a function which has been
 > @@ -17870,7 +17875,8 @@ new_symbol_full (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
 >  
 >  	      if (SYMBOL_CLASS (sym) == LOC_STATIC
 >  		  && SYMBOL_VALUE_ADDRESS (sym) == 0
 > -		  && !dwarf2_per_objfile->has_section_at_zero)
 > +		  && (!dwarf2_per_objfile->section_at_zero
 > +		      || (dwarf2_per_objfile->section_at_zero->flags & SEC_CODE)))

The SEC_CODE test doesn't feel right.
I understand the intent, but someone might put a variable in .text
for a reason.

 >  		{
 >  		  /* When a static variable is eliminated by the linker,
 >  		     the corresponding debug information is not stripped
 > -- 
 > 1.9.3
 > 


  reply	other threads:[~2014-08-22 18:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30  8:21 Revisit gdb/12528 for bare metal targets Yao Qi
2014-08-01 13:29 ` Yao Qi
2014-08-06  6:54 ` [PATCH 1/2] Remove pst from dwarf_decode_lines_1 Yao Qi
2014-08-06  6:54   ` [PATCH 2/2] Check function is GC'ed Yao Qi
2014-08-15  4:40     ` Doug Evans
2014-08-15  6:19       ` Yao Qi
2014-08-20 15:40     ` Pedro Alves
2014-08-13 12:01   ` [PATCH 1/2] Remove pst from dwarf_decode_lines_1 Yao Qi
2014-08-13 18:58     ` Doug Evans
2014-08-14 23:53       ` Yao Qi
2014-08-15  2:04         ` Yao Qi
2014-08-21  8:26 ` [PATCH 1/3] Check function is GC'ed Yao Qi
2014-08-21  8:26   ` [PATCH 3/3] Run dw2-var-zero-addr.exp with --readnow Yao Qi
2014-08-22 18:06     ` Doug Evans
2014-09-19  9:09       ` Yao Qi
2014-08-21  8:26   ` [PATCH 2/3] Check data is GC'ed Yao Qi
2014-08-22 18:02     ` Doug Evans [this message]
2014-08-29 13:32       ` Yao Qi
2014-08-22 17:40   ` [PATCH 1/3] Check function " Doug Evans
2014-08-28 10:50     ` Yao Qi
2014-09-15  8:06       ` Yao Qi
2014-09-15 18:53       ` Doug Evans
2014-09-16  2:40         ` Yao Qi
2014-09-18 16:42           ` Doug Evans
2014-09-19  9:08             ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21495.34225.60705.175416@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox