This is the mail archive of the mailing list for the GDB 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

Nick Clifton <nickc at redhat dot com> writes:

> > 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 ?)

I created a .stabstr section in the input file because I needed to
have a section in an input file which the linker script could put into
the output file correctly.  This is not the only place where this
trick is used.

Using an existing .stabstr section would have to be handled carefully.
The code would have to extract the information, and arrange to replace
it in the output file.  This might not be too hard.

Creating the .stabstr section in the output BFD doesn't work, because
it won't let the linker script function properly.

> > 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.

Well, I'm afraid that you will have to deal with a number of other
cases if you want to avoid adding sections to input files.  Take a
look at elf_link_create_dynamic_sections().


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