public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Re: gas rearranging elf file symbols
@ 2004-10-08  7:18 Jan Beulich
  0 siblings, 0 replies; 8+ messages in thread
From: Jan Beulich @ 2004-10-08  7:18 UTC (permalink / raw)
  To: amodra, binutils

Exactly. I see these two interpretations of the wording: Either there
can be just (at most) one such symbol (for the main source file), which
is the way gcc handles it. Or there can be multiple of them, each one
preceding the local symbols resulting from that file. But I cannot
interpret the wording in a way that would make it match the current
implementation.

Jan

>>> Alan Modra <amodra@bigpond.net.au> 08.10.04 08:29:29 >>>
On Fri, Oct 08, 2004 at 03:23:19PM +0930, Alan Modra wrote:
> the correct file.  You can't do better for globals of course, since
> global symbols are placed after local symbols, losing any
association
> you might infer from the symbol ordering.

Actually, you can't do much about local symbols either.  The ELF gABI
says:

STT_FILE
    Conventionally, the symbol's name gives the name of the source
file
    associated with the object file. A file symbol has STB_LOCAL
    binding, its section index is SHN_ABS, and it precedes the other
    STB_LOCAL symbols for the file, if it is present.

From that wording you could also infer that there should only be one
file symbol, that of the main source file.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: gas rearranging elf file symbols
@ 2004-10-20  6:41 Jan Beulich
  2004-10-20 23:48 ` Alan Modra
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2004-10-20  6:41 UTC (permalink / raw)
  To: amodra; +Cc: binutils, gdb

This doesn't look correct to me. What I believe needs to be cut down is
the number of symbols resulting from (from the assembler's perspective)
consecutive # <line> <file> preprocessor-generated constructs (because
all of them except the last can only be meaningless except for
dependency determination). Explicit .file/.appfile directives should, in
my opinion, always be honoured. If you really want just a single file
symbol, then I'd still see a need to honor the first (or last)
.file/.appfile in preference over any preprocessor-generated ones. Jan

>>> Alan Modra <amodra@bigpond.net.au> 20.10.04 04:29:03 >>>
On Fri, Oct 08, 2004 at 03:59:29PM +0930, Alan Modra wrote:
> STT_FILE
>     Conventionally, the symbol's name gives the name of the source
file
>     associated with the object file. A file symbol has STB_LOCAL
>     binding, its section index is SHN_ABS, and it precedes the other
>     STB_LOCAL symbols for the file, if it is present.
> 
> From that wording you could also infer that there should only be one
> file symbol, that of the main source file.

I'm inclined to implement this.  gcc/gas seem to only emit one file
symbol for C source, so I think it reasonable to do the same for
assembly.  The difference in number of symbols can be quite
significant,
for example glibc/io/write.o on powerpc-linux currently has 38 file
symbols (in a total of 49 symbols).

	* config/obj-elf.c (elf_file_symbol): Only emit one file
symbol.

Any objections from gdb folks?

Index: gas/config/obj-elf.c
===================================================================
RCS file: /cvs/src/src/gas/config/obj-elf.c,v
retrieving revision 1.86
diff -u -p -r1.86 obj-elf.c
--- gas/config/obj-elf.c	8 Sep 2004 20:52:48 -0000	1.86
+++ gas/config/obj-elf.c	20 Oct 2004 02:23:13 -0000
@@ -238,19 +238,24 @@ elf_sec_sym_ok_for_reloc (asection *sec)
 void
 elf_file_symbol (const char *s)
 {
-  symbolS *sym;
+  if (symbol_rootP == NULL
+      || symbol_rootP->bsym == NULL
+      || (symbol_rootP->bsym->flags & BSF_FILE) == 0)
+    {
+      symbolS *sym;
 
-  sym = symbol_new (s, absolute_section, 0, NULL);
-  symbol_set_frag (sym, &zero_address_frag);
-  symbol_get_bfdsym (sym)->flags |= BSF_FILE;
+      sym = symbol_new (s, absolute_section, 0, NULL);
+      symbol_set_frag (sym, &zero_address_frag);
+      symbol_get_bfdsym (sym)->flags |= BSF_FILE;
 
-  if (symbol_rootP != sym)
-    {
-      symbol_remove (sym, &symbol_rootP, &symbol_lastP);
-      symbol_insert (sym, symbol_rootP, &symbol_rootP,
&symbol_lastP);
+      if (symbol_rootP != sym)
+	{
+	  symbol_remove (sym, &symbol_rootP, &symbol_lastP);
+	  symbol_insert (sym, symbol_rootP, &symbol_rootP,
&symbol_lastP);
 #ifdef DEBUG
-      verify_symbol_chain (symbol_rootP, symbol_lastP);
+	  verify_symbol_chain (symbol_rootP, symbol_lastP);
 #endif
+	}
     }
 
 #ifdef NEED_ECOFF_DEBUG

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 8+ messages in thread
* gas rearranging elf file symbols
@ 2004-10-06  8:31 Jan Beulich
  2004-10-08  5:53 ` Alan Modra
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2004-10-06  8:31 UTC (permalink / raw)
  To: binutils

After enabling elf_find_function to actually report a filename if any
can be found, it became immediately obvious that gas prevents this from
being fully functional. This is because gas (a) emits all the file
symbols (resulting from # <line> "<filename>", .file, or .appfile) in a
block and (b) inverts the sequence in which they were encountered. With
this, associating a local symbol with its (pseudo-)source file name is
impossible.

Is anyone able to explain why this works the way it does currently?
This may have been inherited from COFF (where a comment says reordering
is done intentionally), but it would seem wrong there, too.

Thanks, Jan

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-11-10  3:24 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-08  7:18 gas rearranging elf file symbols Jan Beulich
  -- strict thread matches above, loose matches on Subject: below --
2004-10-20  6:41 Jan Beulich
2004-10-20 23:48 ` Alan Modra
2004-11-10  3:24   ` Alan Modra
2004-10-06  8:31 Jan Beulich
2004-10-08  5:53 ` Alan Modra
2004-10-08  6:29   ` Alan Modra
2004-10-20  2:29     ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).