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]

Re: gdb.mi/mi-cli.exp failures


Hi Daniel,

> 1.  stabs.c can create a new section while reading stabs from an input
> BFD.  This means that I can't save and restore a per-section datum
> (output_offset and output_section) around a call to
> bfd_link_add_symbols.
> 
> #0  bfd_section_init (abfd=0x8277980, newsect=0x827b9b4) at /opt/src/gdb/src/bfd/section.c:734
> #1  0x0818039d in _bfd_link_section_stabs (abfd=0x8277980, psinfo=0x827855c, stabsec=0x827cae8,
>     stabstrsec=0x827cb7c, psecinfo=0x827b9c0) at /opt/src/gdb/src/bfd/stabs.c:240
> #2  0x081501d6 in elf_link_add_object_symbols (abfd=0x8277980, info=0xbfffe0b0)
>     at /opt/src/gdb/src/bfd/elflink.h:2305
> #3  0x08148f8b in bfd_simple_get_relocated_section_contents (abfd=0x8277980, sec=0x827cae8,
>     outbuf=0x828f868 "", symbol_table=0x0) at /opt/src/gdb/src/bfd/simple.c:247
> 
> It's doing this:
> 	sinfo->stabstr = bfd_make_section_anyway (abfd, ".stabstr");
> which doesn't make much sense to me; there's _already_ a section named
> .stabstr in the executable, why not use that one?

Hmm, agreed - this probably ought to be a call to
bfd_get_section_by_name().  And if that fails then the code should try
to find the output bfd and create the section there.  (Either that or
else return a failure result.  Can you have a .stabs section without a
.stabsstr section ?)

> Can I not rely on section_count remaining stable for an input BFD?

I think that you ought to be able to rely on this.


> 2.  We call bfd_simple_get_relocated_section_contents twice on the same
> section.  The second time, it crashes.  It appears that pointers to the
> symbol table are stored in the canonicalized relocations, in
> elf_slurp_reloc_table_from_section.  This means that the symbol table
> can no longer be freed.  Should it be allocated via bfd_alloc instead
> of bfd_malloc?

> Note that this is a significant change, since we're talking about the
> pointer table, i.e. the area of size bfd_get_symtab_upper_bound ().

Plus we would now have to ensure that the caller has allocated the
memory in the same bfd, it is passing in the 'symbol_table' pointer.

However, since the relocs are persistent, I think that the symbols
that they use need to be persistent too.  Hence we need to use
bfd_alloc.

Cheers
        Nick


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