Re: objcopy.c: question regarding debugging info handling

[Joerg Wunsch <j at ida dot interface-business dot de>]

First, thanks for the response.

As Alan Modra wrote:

> > This will make a symbol from the symtab go away that is marked as
> > BSF_DEBUGGING even though convert_debugging is true.  Shouldn't that
> > be
> > 
> > 	keep = (strip_symbols != STRIP_DEBUG
> > 		&& strip_symbols != STRIP_UNNEEDED)
> > 	       || convert_debugging;
> > 
> > instead, i. e. when convert_debugging is true, BSF_DEBUGGING symbols
> > should always be kept?
> 
> I think the idea was that write_debugging_info should add used debug
> symbols back.  Obviously, it doesn't do so yet.

Ah, i see.

I think the problem is then only one for COFF.  Any other debug format
doesn't store the debugging information in the symbol table, and
probably behaves the way you describe it.  My problem is that i have
to completely rewrite the symtab entries, virtually from scratch.  The
information stored in the internal debug format is (AFAICT -- please
correct me if i'm wrong) insufficient for this.  Most notably, the
correlation to the file section is missing there.  When i want to
convert an internal debugging symbol into a symtab symbol, i'm
supposed to add a reference to the section to the symbol.  Now, the
easiest way for me to do so is to find the original symtab symbol that
correspdonds to my current debugging symbol, and combine both
information to form the new symtab symbol (that will also contain
debugging information then).

I realize that my suggested change would keep obsolete BSF_DEBUGGING
symbols in the symtab for any other debugging format (since they don't
have the need to completely rewrite the symtab as i do).  So i guess i
need to add another flag to the decision that means `keep any
debugging symbol by now', which is going to be triggered by

convert_debugging || output_format == COFF

Another question: what am i supposed to do with those symtab symbols
(asymbol *) i do no longer need?  I figured it's inappropriate to just
free() them, but how to eventually get rid of them?  Or should i just
not care (as i do now) since once objcopy has been running completely,
the operating system will free the processes memory anyway...

Yet another question. :-)  I see a number of FIXMEs like

    case T_INT:
      /* FIXME: Perhaps the size should depend upon the architecture.  */
      ret = debug_make_int_type (dhandle, 4, false);
      name = "int";
      break;

in rdcoff.c.  When reading an AVR COFF file, these need indeed fixing,
since this is basically a 16-bit architecture (sizeof(int) is usually
2, sizeof(double) is 4).  By now, i worked around this by completely
cloning rdcoff.c into a new file avrcoff.c.  I figure it's probably
better to do all this inside rdcoff.c and avoid the new file, but that
would mean the COFF BFD object needs a notion of the various implied
type sizes.

-- 
J"org Wunsch					       Unix support engineer
joerg_wunsch at interface-systems dot de        http://www.interface-systems.de/~j/