This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] MIPS: microMIPS ASE support


> Hello,
> 
>  Ilie, Joseph: I have some questions for you below, please respond.

  Ilie is on vacations.

> > > +  /* Now adjust the global symbols defined in this section.  */
> > > +  symcount = (symtab_hdr->sh_size / sizeof (Elf32_External_Sym)
> > > +	      - symtab_hdr->sh_info);
> > > +  sym_hashes = start_hashes = elf_sym_hashes (abfd);
> > > +  end_hashes = sym_hashes + symcount;
> > > +
> > > +  for (; sym_hashes < end_hashes; sym_hashes++)
> > > +    {
> > > +      struct elf_link_hash_entry *sym_hash = *sym_hashes;
> > > +
> > > +      if ((sym_hash->root.type == bfd_link_hash_defined
> > > +	   || sym_hash->root.type == bfd_link_hash_defweak)
> > > +	  && sym_hash->root.u.def.section == sec
> > > +	  && sym_hash->root.u.def.value > addr
> > > +	  && sym_hash->root.u.def.value < toaddr)
> > > +	sym_hash->root.u.def.value -= count;
> > > +    }
> > 
> > ...if we're willing to extend the upper bound in this way, I wonder
> > whether there's really any point having an upper bound at all.
> > 
> > Then again, why doesn't the standard range (used by most targets)
> > include toaddr?  If you define an end marker:
> > 
> > end_of_section:
> > 	# nothing after this
> > 
> > then wouldn't end_of_section == toaddr, and shouldn't it be 
> included?
> 
>  Ilie, I'm told you were responsible for this piece of code 
> -- would you 
> please respond to these questions?

  I think we should include "end_of_section == toaddr".
Ex:
	  && sym_hash->root.u.def.value <= toaddr)

> > > +static unsigned long
> > > +find_match (unsigned long opcode, const struct 
> opcode_descriptor insn[])
> > > +{
> > > +    unsigned long indx;
> > > +
> > > +    /* First opcode_table[] entry is ignored.  */
> > > +    for (indx = 1; insn[indx].mask != 0; indx++)
> > > +      if (MATCH (opcode, insn[indx]))
> > > +	return indx;
> > > +
> > > +    return 0;
> > > +}
> > 
> > But _why_ is the first entry ignored?
> 
>  There must be a reason, Ilie?

  I guess Ilie tries to avoid passing a single-entry table into find_match().
But if we do pass a single-entry table into find_match(), 
find_match() may not find the end marker and it will be wrong anyway.
Maybe we just delete all the { 1, 1 } entry in opcode_descriptor [] tables, and
find_match() doesn't ignore the first entry.
And we make sure that each table has end marker at the end.
Thanks!

Regards,
Chao-ying


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]