OK, well that was just an attempted workaround to what I suspect is a BFD
I've attached a patch that can be applied right over the top of the previous
patch I attached to this note. This latest patch prints some debug info to
try to focus in on the source of the problem. Please try this out. Please
capture the screen output and the opreport (if available) and attach them to
a reply. You should see a message on the screen shortly before the seg
fault indicating the name of the image file being processed. Please attach
that file to your reply as well.
IBM Linux Technology Center
----- Original Message -----
From: "Peter Wong" <wpeter@...>
Cc: "Anton Blanchard" <anton@...>; "Ben Elliston" <bje@...>;
Sent: Monday, March 28, 2005 12:00 PM
Subject: Re: [PATCH] Handle recent change in binutils which removed "dotted"
symbols from elf64
> Hi Maynard,
> With the application of your patch below, I still got a segmentation
> when I did "opreport -l" on my HV4 system running RHEL 4.
> Peter Wai Yee Wong
> IBM Linux Performance Team
> email: wpeter@...
> Office: (512) 838-9272, T/L 678-9272; Fax: (512) 838-4663
> 03/25/2005 04:32 "Anton Blanchard" <anton@...>
> PM cc
> t>, "Ben Elliston"
> <bje@...>, Peter
> Re: [PATCH] Handle recent change in
> binutils which removed "dotted"
> symbols from elf64
> I've attached an updated patch that responds to your comments below. I
> changed the configure.in so it would only look at family and not CPU type.
> was also thinking I needed to add a check for the version of BFD, but
> discussion with others, I'm convinced that the present check (compiling
> with -m64 and checking for dotted symbols) is sufficient since gcc's new
> ELF64 format depends on the new binutils/bfd stuff being present anyway.
> In addition, I've tried to respond to some of the concerns voiced by
> too. But because of my use of the new bfd funcion (get_synthetic_symtab),
> really have no choice but to use #if's. I've tried to isolate those as
> as possible into seperate functions so as not to messy up exising code.
> Finally, I've streamlined the new code, removing a call that fetches
> dynamic symbols, and thus not passing any dynamic symbols into
> get_synthetic_symtab. I had tried doing this earlier since it's not
> necessary to include the dynamic symbols, but I couldn't figure out how to
> do it without seg faulting. I finally determined that if I only call this
> function with an elf64 target, then I can pass NULL for the dynamic
> arg. It is possible that this change may help with the seg fault you were
> seeing. I don't know if we were barfing on a dynamic symbol before, but
> we were . . . well, they're gone now, so we should be good.
> Please give this patch a try and let me know if it works.
> Maynard Johnson
> IBM Linux Technology Center
> ----- Original Message -----
> From: "Anton Blanchard" <anton@...>
> To: "Maynard P. Johnson" <maynardj@...>
> Cc: <oprofile-list@...>
> Sent: Thursday, March 24, 2005 12:08 AM
> Subject: Re: [PATCH] Handle recent change in binutils which removed
> symbols from elf64
> > Hi,
> > > Recent changes in binutils removed the so-called "dotted" symbols from
> > > elf64 binaries for PPC64 architectures, leaving just OPDs. This
> > > change was backported by Redhat into RHEL4. Since OProfile relies on
> > > information from these dotted symbols, the opreports done for 64-bit
> > > apps on RHEL 4 on PPC64 architectures did not show correct
> > > information. This patch detects the architecture on which OProfile is
> > > built and conditionally compiles in the appropriate steps to
> > > synthesize the dotted symbols when needed.
> > A few suggestions...
> > +# Determine elf64 symbol format
> > +OS="`uname`"
> > +if test "$OS" = "Linux"; then
> > + family=`uname -m`
> > + if test "$family" = "ppc64"; then
> > + CPU_info="`cat /proc/cpuinfo | grep cpu | cut -d: -f2 |
> > cut -d' ' -f2 | sed '2,$d'`"
> > + case "$CPU_info" in
> > + PPC970*) DO_ELF64_CHECK="yes";;
> > + POWER4*) DO_ELF64_CHECK="yes";;
> > + POWER5*) DO_ELF64_CHECK="yes";;
> > + esac
> > + fi
> > I do builds for POWER5 boxes on my POWER3. I dont think we should be
> > checking for the cpu type at build time.
> > +#if (defined(__powerpc64__) || defined(__powerpc__)) &&
> > __powerpc__ should be defined on both the 32bit and 64bit targets.
> > Thinking about it more, another architecture could potentially have
> > synthetic symbol issues. Would it make more sense to ditch the powerpc
> > specific ifdefs and just wrap stuff in SYNTHETIC_SYMBOL?
> > I tried the patch out on a RHEL4 system and managed to get it to SEGV:
> > Program received signal SIGSEGV, Segmentation fault.
> > (anonymous namespace)::interesting_symbol (sym=0x10247ff8) at
> > 421 if (!(sym->section->flags & SEC_CODE))
> > (gdb) backtrace
> > #0 (anonymous namespace)::interesting_symbol (sym=0x10247ff8) at
> > #1 0x10059bf8 in op_bfd::get_symbols_from_file (this=0xffffe5f0,
> > start=2, symbols=@0xffffe560, debug_file=false) at utility.h:69
> > #2 0x1005a04c in op_bfd::get_symbols (this=0xffffe5f0,
> > at op_bfd.cpp:607
> > #3 0x1005ab18 in op_bfd (this=0xffffe5f0, archive_path=@0x1011c5b0,
> > fname=@0x67636332, symbol_filter=@0x1011d448, ok=@0xffffe580)
> > at op_bfd.cpp:373
> > #4 0x100314c0 in populate_for_image (archive_path=@0x1011c5b0,
> > samples=@0xffffe560, ip=@0x10131518, symbol_filter=@0xffc8d10)
> > at populate.cpp:57
> > #5 0x100075dc in (anonymous namespace)::opreport
> > at stl_list.h:130
> > #6 0x10014248 in run_pp_tool (argc=270827512, argv=0xffffea44,
> > fct=0x100073f0 <(anonymous
> namespace)::opreport(std::vector<std::string, std::allocator<std::string>
> const&)>) at common_option.cpp:107
> > #7 0x10004cf4 in main (argc=270827512, argv=0xffc8d18) at
> > (gdb) print sym
> > $1 = (asymbol *) 0x10247ff8
> > (gdb) print sym->section
> > $2 = (bfd_section *) 0xc4ee4
> > Anton
> (See attached file: ppc64-elf-patch-oprofCVS-03.25.05)