From: John L. <le...@mo...> - 2005-03-22 20:30:20
|
On Mon, Mar 21, 2005 at 02:14:16PM -0600, Maynard P. Johnson wrote: > 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. Could you please elaborate on the exact problem? The patch is pretty ugly. Why do we rely on such symbols? regards joohn |
From: William C. <wc...@re...> - 2005-03-22 21:43:59
|
John Levon wrote: > On Mon, Mar 21, 2005 at 02:14:16PM -0600, Maynard P. Johnson wrote: > > >>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. > > > Could you please elaborate on the exact problem? The patch is pretty > ugly. Why do we rely on such symbols? > > regards > joohn It appears that some of the symbols are not stored directly in the file and this is a way to generate them. Otherwise OProfile doesn't find any symbols for the binary. Maynard, I noticed that the recent SRPMs for GDB (gdb-6.3.0.0-0.31.src.rpm) also have changes to support the synthetic symbols in the gdb-6.3-ppcdotsym-20050126.patch. However, the patch doesn't have the architecture specific preprocessor ifs? How similar is the gdb patch to what is being done in this oprofile patch? Could the gdb patch be used as a guide to refine the oprofile patch? Also is adding change going to break things for platforms with olderversions of bfd, e.g. using development version of oprofile on RHEL3? -Will |
From: John L. <le...@mo...> - 2005-03-22 21:59:20
|
On Tue, Mar 22, 2005 at 04:43:44PM -0500, William Cohen wrote: > >>Recent changes in binutils removed the so-called "dotted" symbols from > >>elf64 binaries for PPC64 architectures, leaving just OPDs. This > > It appears that some of the symbols are not stored directly in the file > and this is a way to generate them. Otherwise OProfile doesn't find any > symbols for the binary. Yuck... any pointers to the binutils mailing list thread describing the changes and the need for them? regards john |
From: Maynard P. J. <may...@us...> - 2005-03-22 23:43:54
|
----- Original Message ----- From: "William Cohen" <wc...@re...> To: "John Levon" <le...@mo...> Cc: "Maynard P. Johnson" <may...@us...>; <opr...@li...> Sent: Tuesday, March 22, 2005 3:43 PM Subject: Re: [PATCH] Handle recent change in binutils which removed "dotted" symbols from elf64 > John Levon wrote: > > On Mon, Mar 21, 2005 at 02:14:16PM -0600, Maynard P. Johnson wrote: > > > > > >>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. > > > > > > Could you please elaborate on the exact problem? The patch is pretty > > ugly. Why do we rely on such symbols? > > > > regards > > joohn > > > It appears that some of the symbols are not stored directly in the file > and this is a way to generate them. Otherwise OProfile doesn't find any > symbols for the binary. I'm not an expert in the binary format for ppc64, but the upshot is that prior to this change in binutils, you would see two symbols for each function: one for the function descriptor and one for the actual function (containing the function's vma). The dotted symbol was the actual function and that's what OProfile used. The patch simply synthesizes those dotted symbols in the case where they aren't present (i.e., if using recent binutils code). > > Maynard, > I noticed that the recent SRPMs for GDB (gdb-6.3.0.0-0.31.src.rpm) also > have changes to support the synthetic symbols in the > gdb-6.3-ppcdotsym-20050126.patch. However, the patch doesn't have the > architecture specific preprocessor ifs? How similar is the gdb patch to > what is being done in this oprofile patch? Could the gdb patch be used > as a guide to refine the oprofile patch? I haven't looked at the gdb patch. IBM's binutils guy pointed me in the direction of nm.c in binutils and suggested using that as a model. I don't know how I'd get around not using some #ifdef's since the dotted symbols is only an issue on Linux/PPC64. > > Also is adding change going to break things for platforms with > olderversions of bfd, e.g. using development version of oprofile on RHEL3? No, it should be a NOP for platforms that don't need it. On PPC64 platforms, the configure.in changes I made will perform a compilation of a test program and determine whether or not the dotted symbols are present; then #define (or not) the PPC64_DOTTED_SYMS constant. > > -Will > > |
From: John L. <le...@mo...> - 2005-03-22 23:55:37
|
On Tue, Mar 22, 2005 at 05:40:50PM -0600, Maynard P. Johnson wrote: > > It appears that some of the symbols are not stored directly in the file > > and this is a way to generate them. Otherwise OProfile doesn't find any > > symbols for the binary. > I'm not an expert in the binary format for ppc64, but the upshot is that > prior to this change in binutils, you would see two symbols for each > function: one for the function descriptor and one for the actual function > (containing the function's vma). The dotted symbol was the actual function > and that's what OProfile used. The patch simply synthesizes those dotted > symbols in the case where they aren't present (i.e., if using recent > binutils code). So shouldn't this patch be in libbfd? I'm not clear on why they were removed so maybe there's some reason that's unsuitable regards john |
From: Maynard P. J. <may...@us...> - 2005-03-23 15:02:33
|
----- Original Message ----- From: "John Levon" <le...@mo...> To: "Maynard P. Johnson" <may...@us...> Cc: "William Cohen" <wc...@re...>; <opr...@li...> Sent: Tuesday, March 22, 2005 5:55 PM Subject: Re: [PATCH] Handle recent change in binutils which removed "dotted" symbols from elf64 > On Tue, Mar 22, 2005 at 05:40:50PM -0600, Maynard P. Johnson wrote: > > > > It appears that some of the symbols are not stored directly in the file > > > and this is a way to generate them. Otherwise OProfile doesn't find any > > > symbols for the binary. > > I'm not an expert in the binary format for ppc64, but the upshot is that > > prior to this change in binutils, you would see two symbols for each > > function: one for the function descriptor and one for the actual function > > (containing the function's vma). The dotted symbol was the actual function > > and that's what OProfile used. The patch simply synthesizes those dotted > > symbols in the case where they aren't present (i.e., if using recent > > binutils code). > > So shouldn't this patch be in libbfd? Apparently Alan Modra did not believe so when he made the original change. > I'm not clear on why they were > removed so maybe there's some reason that's unsuitable External pressure was applied to get rid of the dotted symbols in elf64 on PPC64 architectures since it was different from other 64-bit architectures. Alan Modra was the binutils person who pointed me at nm.c to use as a model. He also directed me to this URL for background: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00557.html. I hope this clears up the question of why it was done and how it affects tools such as OProfile. Regards, Maynard > > regards > john > > > ------------------------------------------------------- > This SF.net email is sponsored by: 2005 Windows Mobile Application Contest > Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones > for the chance to win $25,000 and application distribution. Enter today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > > |
From: Maynard P. J. <may...@us...> - 2005-03-23 17:23:45
|
----- Original Message ----- From: "William Cohen" <wc...@re...> To: "John Levon" <le...@mo...> Cc: "Maynard P. Johnson" <may...@us...>; <opr...@li...> Sent: Tuesday, March 22, 2005 3:43 PM Subject: Re: [PATCH] Handle recent change in binutils which removed "dotted" symbols from elf64 > John Levon wrote: > > On Mon, Mar 21, 2005 at 02:14:16PM -0600, Maynard P. Johnson wrote: > > > > > >>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. > > > > > > Could you please elaborate on the exact problem? The patch is pretty > > ugly. Why do we rely on such symbols? > > > > regards > > joohn > > > It appears that some of the symbols are not stored directly in the file > and this is a way to generate them. Otherwise OProfile doesn't find any > symbols for the binary. > > Maynard, > I noticed that the recent SRPMs for GDB (gdb-6.3.0.0-0.31.src.rpm) also > have changes to support the synthetic symbols in the > gdb-6.3-ppcdotsym-20050126.patch. However, the patch doesn't have the > architecture specific preprocessor ifs? How similar is the gdb patch to > what is being done in this oprofile patch? Could the gdb patch be used > as a guide to refine the oprofile patch? I checked into GDB. That project has arch-specific directories, so they can get by without the arch-specific #if's in the code. Regards, Maynard > > Also is adding change going to break things for platforms with > olderversions of bfd, e.g. using development version of oprofile on RHEL3? > > -Will > > |