This is the mail archive of the 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]
Other format: [Raw text]

bfd/syms.c bfd_decode_symclass patch proposal for gprof problem

We have a customer using gprof on an embedded target, and running into the
problem that gprof doesn't generate output for all of the functions.  The
missing functions are not in the text section.  They were put in special
sections via an __attribute__ ((section ("foo"))), and these special sections
are handled in the linker script file.  Gprof checks for text sections by
calling bfd_get_symbol_info.  This eventually takes us to coff_section_type
which checks for text sections by looking at the section name, and fails
because we have a non-standard section name.  We can do better here by using
the section flags which is the ELF way of doing things.

By the way, the gprof output is being generated by sid.  sid is a simulation
environment that has support for generating gprof output without requiring
any compiler support.  It isn't hard to fake gprof in a simulator.  This
doesn't affect anything though, as you have the same gprof problem even if you
do things the traditional way via compiler instrumentation.  Sid info can be
found at

I tried writing a patch to check for section flags after checking the
section names.  This reduces the chance of breaking anything, since we only
get different results for sections that can not be identified currently.  This
patch works for the testcase I have.  All functions are reported by gprof,
including functions in non-standard text sections.

I put my new code in the generic bfd_decode_symclass, since I thought it
seemed reasonable to check section flags for all object type formats.  This
code could instead go into the elf specific bfd_symbol_info function.  This
code causes us to return 'd' for misc data sections like .note, and 't'
for misc text sections like .plt.  This seems relatively harmless.  I'm
not sure if the order that I check for flags is right, I didn't try very
hard to check whether this handles all sections correctly.

I tried looking for places that would be affected by this change.
bfd_get_symbol_info is only used in 3 places.  It is used in nm, and it is
important not to change this as some people have scripts that parse nm
output.  My code can only affect symbols that are currently '?', so it should
be OK.  It is used in binutils/rddbg.c, but that code seems pretty useless
now, since it only handles the '-' type, and only aout targets return the
'-' type.  Not many people use aout anymore.  My code doesn't emit '-' so there
should be no effect here.  And of course, it is used in gprof as I mentioned
above.  Gprof only cares about 'T', 't' and 'W' results, so gprof behaves
differently only if you have a SHF_CODE section which isn't one of the
standard text section names, and that should be OK.  bfd_decode_symclass is
used in bfd/tekhex.c.  Emitting extra sections to the tekhex output should be
OK, since they would be needed for correctness anyways.  It is also used in
objcopy.  objcopy only checks for 'I', and my patch doesn't emit that, so
there is no change to objcopy.

I ran all binutils testsuites with my patch, and there was no change.
However, gprof doesn't have any testsuite, so I'm not sure this did anything

2002-07-04  Jim Wilson  <>

	* syms.c (elf_section_type): New.
	(bfd_decode_symclass): Call elf_section_type.

Index: syms.c
RCS file: /cvs/src/src/bfd/syms.c,v
retrieving revision 1.23
diff -p -r1.23 syms.c
*** syms.c	25 Jun 2002 09:40:45 -0000	1.23
--- syms.c	5 Jul 2002 00:57:31 -0000
*************** CODE_FRAGMENT
*** 315,320 ****
--- 315,321 ----
  #include "aout/stab_gnu.h"
  static char coff_section_type PARAMS ((const char *));
+ static char elf_section_type PARAMS ((const struct sec *));
  static int cmpindexentry PARAMS ((const PTR, const PTR));
*************** coff_section_type (s)
*** 589,594 ****
--- 590,630 ----
    return '?';
+ /* Return the single-character symbol type corresponding to section
+    SECTION, or '?' for an unknown section.  This uses section flags to
+    identify sections.
+    FIXME These types are unhandled: c, i, e, p.  If we handled these also,
+    we could perhaps obsolete coff_section_type.  */
+ static char
+ elf_section_type (section)
+      const struct sec *section;
+ {
+   if (section->flags & SEC_CODE)
+     return 't';
+   if (section->flags & SEC_DATA)
+     {
+       if (section->flags & SEC_READONLY)
+ 	return 'r';
+       else if (section->flags & SEC_SMALL_DATA)
+ 	return 'g';
+       else
+ 	return 'd';
+     }
+   if ((section->flags & SEC_HAS_CONTENTS) == 0)
+     {
+       if (section->flags & SEC_SMALL_DATA)
+ 	return 's';
+       else
+ 	return 'b';
+     }
+   if (section->flags & SEC_DEBUGGING)
+     return 'N';
+   return '?';
+ }
*************** bfd_decode_symclass (symbol)
*** 639,645 ****
    if (bfd_is_abs_section (symbol->section))
      c = 'a';
    else if (symbol->section)
!     c = coff_section_type (symbol->section->name);
      return '?';
    if (symbol->flags & BSF_GLOBAL)
--- 675,685 ----
    if (bfd_is_abs_section (symbol->section))
      c = 'a';
    else if (symbol->section)
!     {
!       c = coff_section_type (symbol->section->name);
!       if (c == '?')
! 	c = elf_section_type (symbol->section);
!     }
      return '?';
    if (symbol->flags & BSF_GLOBAL)

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