x86_64: gprof reports run times much longer than reality

2006-06-21 Thread Jeremy Buhler 

PROBLEM:
On all of my Linux x86_64 systems, when I build code instrumented for 
profiling with gcc -pg, the running times reported for the code by gprof 
are many times the actual runtime of the program.  This problem is 
specific to x86_64; the times for the same code are correct on 32-bit 
x86 Linux.  The problem on x86_64 occurs independently of whether I 
compile with -m32 or -m64, and independently of the optimization level 
of the compilation.


A simple example is the following program "braindead.c":

unsigned int x;

void do_something()
{
  unsigned int j;
  for (j = 0; j < (1U << 31); j++)
{
  x = (j * j + j)/ 1;
}
}

int main()
{
  do_something();
  return 0;
}

Here's what I see:

> gcc -O2 -pg braindead.c
> time a.out
5.030u 0.001s 0:05.03 100.0%0+0k 0+0io 0pf+0w
> gprof a.out
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls   s/call   s/call  name
101.33 50.9750.97150.9750.97  do_something
[...]
ndex % timeself  childrencalled name
   50.970.00   1/1   main [2]
[1]100.0   50.970.00   1 do_something [1]
---
 
[2]100.00.00   50.97 main [2]
   50.970.00   1/1   do_something [1]
---

PLATFORM:
Linux 2.6.x x86_64 (x86_64-uknown-linux-gnu)
(observed with RedHat 2.6.9 and 2.6.10 kernels)
(observed on both AMD Opteron and Intel Pentium D)

TOOLCHAIN:
gcc 4.1.1 (same observed with gcc 3.4.5)
binutils nightly 0621 (same observed with older releases)
glibc 2.3.4

 Jeremy


smime.p7s
Description: S/MIME Cryptographic Signature
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Possible bug with using "-static" and "-dynamic" on the same command

2006-06-21 Thread Alan Modra 
On Tue, Jun 20, 2006 at 07:29:58PM +0200, Soeren Gerlach wrote:
> I don't understand the problem at all. "-shared" means to create a shared 
> library. On
> the other hand "-Bstatic" means to link a library statically into the target. 
> On my
> oppinion (sorry, I'm only an application developer ) these two things are 
> different
> issues what is the reason they can't work together? And finally: Until 
> 2.15.90 it worked
> and only from  2.15.94 and above this seems to be "broken".

Correct.  See http://sources.redhat.com/ml/binutils/2005-07/msg00503.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: internal error in bfd_cache_lookup_worker

2006-06-21 Thread Alan Modra 
On Tue, Jun 20, 2006 at 05:03:19PM -0700, Eric Hodel wrote:
> This bug appears on the second run of a command.  I may be doing  
> something BFD/GDB considers sneaky.  This script uses RubyInline  
> which compiles and dynamically links a shared library.  Each run  
> removes the shared library forcing it to be rebuilt.  Perhaps BFD  
> thinks the library hasn't changed and bad things happen?

Yes, deleting the file while bfd was holding it open is "sneaky".
This is really a gdb bug, and bfd should not be reporting it as
an internal error.

See http://sourceware.org/ml/binutils/2005-10/msg00390.html
and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332184

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations

2006-06-21 Thread cgray at cse dot unsw dot edu dot au 

--- Additional Comments From cgray at cse dot unsw dot edu dot au  
2006-06-22 06:59 ---
I'm confused. You don't believe that ld doing these relocations creates a fixed
fixed address relationship between segments? Or you don't believe that this is
what the IA64 ABI is saying you can't do?

If I compile some simple code, say,

printf( "string" );

ld applies relocations to get:

addl r14=-99976,r1 ;;
...
ld8 r32=[r14]

However, the -99976 is *much* bigger than the size of the read/write data
section the gp is in, as shown here: (leading zeros removed for formatting)

  LOAD off0x0005cb50 vaddr 0x0006cb50 paddr 0x6cb50 align 2**16
filesz 0x2428 memsz 0x49d0 flags rw-

So the relocated code assumes a fixed address relationship between sections. If
I load the read-only data at a modified offset, things crash.

You claim "offset from GP is fixed in executable or shared library", however
this is only true at linktime for read/write data. Only the dynamic linker can
extend this to read-only data. The ABI says so. 

This only seems to work for the current VM system in the current version of
Linux. I'd like to supply you with a small test case, however that would require
also supplying you with a whole new VM system, or in my case, OS.

I think it's very clear from the emitted code that ld does *not* obey what is
specified in the ABI, so I don't think sample code is really that necessary. Any
code which uses static read-only data can be used for testing.

If ld is fine with being by default non-ABI compliant, is it not possible to
have command line flags to disable these relocations? Alternatively, do they
already exist and are just undocumented?

Thanks,
 Chuck

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2809

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils