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]

Re: binutils 2.11 sh-rtems/sh-elf dies building gcc




amodra@one.net.au wrote:
> 
> On Wed, Apr 11, 2001 at 07:37:42AM -0500, Joel Sherrill wrote:
> > In fact line 3335 is in the routine tc_gen_reloc which is
> > clearly inside a BFD_ASSEMBLER ifdef so I am pretty sure
> > bfd_gas=yes. :)
> 
> OK, this time I actually looked at the source instead of jumping
> to wrong conclusions, but I can't see how you can arrive at the
> result you get. :-(  Try running under gdb with a breakpoint at
> the offending as_bad_where, then look at the stdoutput bfd info.
> xvec->reloc_type_lookup should be pointing at
> sh_elf_reloc_type_lookup.  If it isn't you probably have some sort
> of build problem.  If it is, you might have a compiler problem,
> wild pointers, or any of a range of nasty problems.

Why elf?  This is supposed to be coff.

To follow up a bit more ...

We have duplicated this problem on Linux and FreeBSD hosts.
I have now duplicated this bug using the sh-coff target and
am using gdb on that as-new with the j.s file I posted earlier.

Breaking at line 3328:

3327      rel->howto = bfd_reloc_type_lookup (stdoutput, r_type);
3328      if (rel->howto == NULL)
3329        {
3330          as_bad_where (fixp->fx_file, fixp->fx_line,

(gdb) p *stdoutput
$3 = {filename = 0x8082d84 "a.out", xvec = 0x808fce0, iostream =
0x809fed8,
  cacheable = true, target_defaulted = false, lru_prev = 0x809fe40,
  lru_next = 0x809fe40, where = 0, opened_once = true, mtime_set =
false,
  mtime = 0, ifd = 0, format = bfd_object, direction = write_direction,
  flags = 0, origin = 0, output_has_begun = false, sections = 0x80c4ca4,
  section_count = 3, start_address = 0, symcount = 10, outsymbols =
0x80c57a8,
  arch_info = 0x8090820, arelt_data = 0x0, my_archive = 0x0, next = 0x0,
  archive_head = 0x0, has_armap = false, link_next = 0x0, archive_pass =
0,
  tdata = {aout_data = 0x80c4c38, aout_ar_data = 0x80c4c38,
    oasys_obj_data = 0x80c4c38, oasys_ar_data = 0x80c4c38,
    coff_obj_data = 0x80c4c38, pe_obj_data = 0x80c4c38,
    xcoff_obj_data = 0x80c4c38, ecoff_obj_data = 0x80c4c38,
    ieee_data = 0x80c4c38, ieee_ar_data = 0x80c4c38, srec_data =
0x80c4c38,
    ihex_data = 0x80c4c38, tekhex_data = 0x80c4c38, elf_obj_data =
0x80c4c38,
    nlm_obj_data = 0x80c4c38, bout_data = 0x80c4c38,
    sun_core_data = 0x80c4c38, sco5_core_data = 0x80c4c38,
    trad_core_data = 0x80c4c38, som_data = 0x80c4c38,
    hpux_core_data = 0x80c4c38, hppabsd_core_data = 0x80c4c38,
    sgi_core_data = 0x80c4c38, lynx_core_data = 0x80c4c38,
    osf_core_data = 0x80c4c38, cisco_core_data = 0x80c4c38,
    versados_data = 0x80c4c38, netbsd_core_data = 0x80c4c38, any =
0x80c4c38},
  usrdata = 0x0, memory = 0x809fec8}     


Which field now?

> --
> Alan Modra

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


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