Leading character for BINARY format ?

[Nick Clifton]

Hi Ian,

:    The problem is that BFD generates these symbols with a leading
:    underscore, but in the BFD target vector it sets the
:    'symbol_leading_char' field to 0.  This seems to me to be incorrect.
:    I think that it should be set to '_'.
: 
: No.  If we set symbol_leading_char to '_', then logically the symbols
: are named without a leading underscore.  symbol_leading_char is a
: symbol which is added to the start of the symbol as seen from C.  So
: if symbol_leading_char is '_', then the symbols as seen from C
: logically have no underscore.  But I think the symbols logically
: should have a leading underscore, since they are system generated and
: therefore should not conflict with user symbols.

Except of course that in this case there are no user symbols.  Well
not from the binary format file anyway.

BTW - I am a little confused on name space rules here.  I thought
that a single underscore prefix was allowed in the user domain, but
that a double underscore prefix was not. ie:

     int a;  // legal C
     int _a; // legal C
     int __a;// illegal C - it might conflict with a symbol in the system name space

:    No.  The problem is that is not (currently) possible to strip the
:    leading underscores from the symbols generated by BFD for a binary
:    format input using the --remove-leading-char switch to objcopy.
: 
: This is true, but I don't yet see why it is a problem.  If you compile
: this file using ELF:
:     int _i;
: you can't use --remove-leading-char to remove that underscore either.
: 
: I don't think anything would break if we changed symbol_leading_char
: for the binary object file format.  But I don't see why it is right to
: do so.

OK - I withdraw my patch then.

: I do think objcopy should have an option to rename symbols using a sed
: style regexp.  But I've never gotten around to implementing that.

Oh the things we could do if we had an unlimited amount of spare
time...

Cheers
	Nick