This is the mail archive of the binutils@sourceware.cygnus.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: finding the file of a local symbol in BFD


   Date: Mon, 13 Sep 1999 17:58:21 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   In an ELF symbol table, all local symbols (e.g., C static things) come
   at the beginning of the symbol table.

Yes (except for some versions of MIPS ELF).

   As I understand it, all the
   local symbols from a given compilation unit come in a clump, preceded
   by an STT_FILE symbol whose name is the name of the source file for
   that compilation unit.  So, given this information, you can discover
   which compilation unit a symbol is local to, and thus you can reliably
   distinguish between local symbols with the same name.

This is the convention.  It relies on the compiler doing the right
thing.

(I'm drawing a pedantic distinction between the first statement above,
which is guaranteed by the assembler and linker, and the second, which
is true provided the compiler generates .file pseudo-ops as needed.)

   In BFD, STT_FILE symbols have the BSF_FILE flag associated with them.
   Does BFD guarantee to preserve the order of the symbols?  That is,
   will the symbols as I retrieve them from BFD still appear ordered by
   compilation unit and preceded by a BSF_FILE symbol?

Yes, BFD preserves the order of the ELF symbols when it returns the
BFD asymbol list.

   How portable is this information?  Is there any way to determine the
   compilation unit to which a local symbol belongs that works regardless
   of the underlying object file format?

More or less.  However, at least at present, BFD only uses the
BSF_FILE flag for ELF symbols.

The a.out linker will create an N_TEXT symbol for each object file.
You may be able to use that to identify local symbols accurately,
although offhand I'm not sure how you can tell a file symbol from
other symbols.  Except that they typically have a `.' in them, I
suppose.

The COFF compiler should generate a .file pseudo-op, which the
assembler will turn into a C_FILE symbol and the linker will
preserve.  You can use to identify local symbols correctly.

Ian

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