This is the mail archive of the binutils@sources.redhat.com 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]

bfd/elf-m10300.c: odd code



In bfd/elf-m10300.c (mn10300_elf_relax_section) is code that looks,
in general, like this:

		  /* Look at each function defined in this section and
		     update info for that function.  */
		  isymend = isymbuf + symtab_hdr->sh_info;
		  for (isym = isymbuf; isym < isymend; isym++)
		    {
			...
		    }

		  symcount = (symtab_hdr->sh_size / sizeof (Elf32_External_Sym)
			      - symtab_hdr->sh_info);
		  hashes = elf_sym_hashes (input_bfd);
		  end_hashes = hashes + symcount;
		  for (; hashes < end_hashes; hashes++)
		    {
		      hash = (struct elf32_mn10300_link_hash_entry *) *hashes;
		      if ((hash->root.root.type == bfd_link_hash_defined
			   || hash->root.root.type == bfd_link_hash_defweak)
			  && hash->root.root.u.def.section == section
			  && ELF_ST_TYPE (isym->st_info) == STT_FUNC)
			compute_function_info (input_bfd, hash,
					       (hash)->root.root.u.def.value,
					       contents);
		    }

A few things make me suspicious here:

1. isym is "left dangling" after the first loop, yet used in the
   second loop.

2. isym is used inside the second loop, but nothing changes it (I
   would have expected it to be tested outside the loop).

3. isym is not validated to ensure it points to valid memory.

#3 caused a segfault for me, which is why I noticed it.  The sym array
was right at the end of memory, and the dangling sym was beyond EOM.

Is this code right?  Is something non-obvious happening here?


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