From: Philippe E. <ph...@cl...> - 2002-03-11 05:29:17
|
A restart from the thread with Norbert showing problem with line number information with gcc -2.95.3 Continuing an IIRC discussion with John and restarting it from a school case test oprofpp -l works fine with gcc-2.91 or 3.0 but with 2.95.3: 08049320 229 29.6248 test_empty(int const *, int, int) /root/ram-latency.cpp:0 08049360 544 70.3752 test_mem(int const *, int, int) /root/ram-latency.cpp:0 note the 0 line number objdump -d -S shows compiled with gcc-2.95.3 08049320 <test_empty__FPCiii>: 8049320: 55 pushl %ebp [snip prolog] 8049328: 53 pushl %ebx static int test_empty(const int * data, int sz, int stride) { 8049329: 8b 7d 0c movl 0xc(%ebp),%edi compiled with gcc 2.91 or 3.0 080487ec <test_empty__FPCiii>: static int test_empty(const int * data, int sz, int stride) { 80487ec: 55 pushl %ebp [snip prolog] 80487f2: 8b 75 10 movl 0x10(%ebp),%esi so with 2.95.3 linenr info are wrong, the function prolog does not contain valid linenr information. The problem occurs whith any set of compil options I've tried. The features to see linenr info with -l comes with: 2001-12-01 Philippe Elie <ph...@cl...> ... * pp/oprofpp.cpp: allow to use --output-linenr-info with --list-symbols. but the problem seems from the start (tested with -L on 0.0.6) I compile with 2.91 or 3.0 so ... The gdb behavior is wrong also, it give the function entry point slightly after the start of function, it's probably a well known bug. Source annotation is also wrong from the same problem. samples inside function are correctly annotated but the function itself does not receive the right annotation. We must fix the problem: - a (probably ugly) hack as work-around (looking forward in vma ?) - or document the bug, it's inside 2.95.3 I think we have never noticed that because nobody use -L or -l and -o. Norbert, as a temporary work-around, use -L -o instead of -l -o, the output is a little what more voluminous but allow to deduce the linenr, or don't use -o with -l, or grep your source to retrieve the right position in the source. I'll cc you if we find a right fix. regards, Phil |
From: John L. <le...@mo...> - 2002-03-11 10:38:33
|
On Mon, Mar 11, 2002 at 06:19:45AM +0100, Philippe Elie wrote: > objdump -d -S shows > compiled with gcc-2.95.3 > > 08049320 <test_empty__FPCiii>: > 8049320: 55 pushl %ebp > [snip prolog] > 8049328: 53 pushl %ebx > > static int test_empty(const int * data, int sz, int stride) > { > 8049329: 8b 7d 0c movl 0xc(%ebp),%edi Can you ask about this on the gcc lists please ? a GNATS bug number would be helpful ... I suppose we can advance the VMA, we'll just have to try it. I don't suppose you fancy looking at what gdb does. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |
From: Philippe E. <ph...@cl...> - 2002-03-13 21:18:38
|
From: "John Levon" <le...@mo...> Cc: <opr...@li...>; "Norbert Kaufmann" <nor...@sc...> Sent: Monday, March 11, 2002 11:35 AM > On Mon, Mar 11, 2002 at 06:19:45AM +0100, Philippe Elie wrote: > > > objdump -d -S shows > > compiled with gcc-2.95.3 I'm committing a work around. It does not work perfectly but the number of failure to retrieve correct linenr (rather approximately correct) for tincas decrease from 835 to 173 the remaining are C++ inline function mainly in std:: John, I open a bug entry and will document later the problem and issue > > static int test_empty(const int * data, int sz, int stride) > > { > > 8049329: 8b 7d 0c movl 0xc(%ebp),%edi > > Can you ask about this on the gcc lists please ? a GNATS bug number > would be helpful ... I forget to ask, but searching through GNATS gives no result. I'm unsure if 2.95.3 is already maintained and even if it's a regression ensuring right debug info for (an incoming ?) 2.95.3 seems worthwhile. > I suppose we can advance the VMA, we'll just have to try it. I don't > suppose you fancy looking at what gdb does. That's the approch I take. Beside this problems it seems than many C++ inline have no right linenr debug info. I have not found a work-around for this, scanning forward just retrieve linenr info from the function containaing the inline call. In any case the samples are not lost but accumulated at the call site. Further tests in this area are probably necessary. Norbert : > > Ok, seems I should upgrade my system. hum, trying to upgrade to 3.0 is painfull, the C++ ABI is not compatible with the C++ ABI of 2.95, and eg you can't link program compiled with 3.0 with a QT shared libs compiled with 2.95 ... regards, Phil |
From: John L. <le...@mo...> - 2002-03-13 21:36:06
|
On Wed, Mar 13, 2002 at 10:07:44PM +0100, Philippe Elie wrote: > I'm committing a work around. It does not work perfectly but > the number of failure to retrieve correct linenr (rather approximately > correct) for tincas decrease from 835 to 173 the remaining are C++ > inline function mainly in std:: Hmmph, ok. > John, I open a bug entry and will document later the problem and issue thanks. > I forget to ask, but searching through GNATS gives no result. I'm > unsure if 2.95.3 is already maintained and even if it's a regression > ensuring right debug info for (an incoming ?) 2.95.3 seems worthwhile. This has just come up on gcc list actually, I'm hoping something useful turns up. the thread has "stabs" in the subject iirc regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |
From: Osiris P. <ope...@sw...> - 2002-03-14 04:45:06
|
As I said, I installed RedHat 7.2 (kernel 2.4.7-10). I loaded oprofile-0.1. ./Configure --with-linux=/usr/src/linux-2.4 ./make ./make install All worked fine. I have a /lib/modules/2.4.7-10/oprofile/oprofile.o Questions: 1) How can I convert a vmlinuz to a vmlinux (decompress it?) ? This is required for the op_start command. 2) when insmod oprofile.o, it fails with "init_module: Device or resource busy" Sorry if this is taking much longer than expected, but I have already installed RedHat 7.2 5 times now and tried to rebuilt the kernel with Pentium4 settings but each time I try it, something else does not work (network, X settings, won't boot, ...) Thanks, Osiris |
From: John L. <le...@mo...> - 2002-03-14 13:35:46
|
On Wed, Mar 13, 2002 at 08:44:08PM -0800, Osiris Pedroso wrote: > 1) How can I convert a vmlinuz to a vmlinux (decompress it?) ? This is > required for the op_start command. You really need the vmlinux from your build. Though if you're not doing kernel profiling you can use any file you like ... > 2) when insmod oprofile.o, it fails with "init_module: Device or resource > busy" well it's in RTC mode, so you need to compile out the RTC driver from your kernel. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such. |
From: Philippe E. <ph...@cl...> - 2002-03-14 21:20:43
|
From: "John Levon" <le...@mo...> Sent: Thursday, March 14, 2002 2:32 PM > On Wed, Mar 13, 2002 at 08:44:08PM -0800, Osiris Pedroso wrote: > > > 1) How can I convert a vmlinuz to a vmlinux (decompress it?) ? This is > > required for the op_start command. > > You really need the vmlinux from your build. Though if you're not doing > kernel profiling you can use any file you like ... and, if you have not make clean or make mrproper after building your kernel, it must be in /usr/src/linux-2.4/ I'm unsure than with RH 7.2 you have qt2 installed and so on you can't use oprof_start rather op_start... > > 2) when insmod oprofile.o, it fails with "init_module: Device or > > resource busy" > > well it's in RTC mode, so you need to compile out the RTC driver from > your kernel. John, we need something like in op_rtc.c #ifndef CONFIG_RTC /* is it the right identifier ? */ printk("No RTC ..."); #endif return EBUSY; Osiris, I details a litlle what more a previous John's mail about what to do. 1) change the op_cpu enum adding a CPU_P4 2) change op_init::get_cpu_type() to return CPU_P4 when detecting a P4 3) look where and how OP_MAX_COUNTERS is defined, change the definition to allow at least the 18 P4 counters. 4) write an module/op_p4.c which must the counter part of op_nmi.c and fill an op_int_operations with empty place holder function. 5) change oprofile.c::oprof_init() to handle CPU_P4 So at this point you must get a non-working P4 module skeleton then post it here. After that I think you must get a more precise idea on how the module work and what work is needed. Most of the functionnality for P4 are identical than for P2/Athlon but IMHO it's preferable, for now, to cut and copy code from op_nmi.c to op_P4.c If you find this information too or not enough detailed, just flame me. regards, Philippe Elie |
From: Osiris P. <ope...@sw...> - 2002-03-15 05:14:39
|
> well it's in RTC mode, so you need to compile out the RTC driver from > your kernel. I tried, (several times) ... Messages stop during boot at: calibrating APIC timer ... ..... cpu clock speed is 1296.0977 Mhz ..... host bus clock speed is 0.0000 Mhz cpu: 0, clocks: 0, slice: 0 There is no output after the last 0 above. The machine hangs until hard reset (CTRL+ALT+DEL has no effect). Any hints ? Osiris |
From: Philippe E. <ph...@cl...> - 2002-03-16 00:09:27
|
From: "Osiris Pedroso" <ope...@sw...> Sent: Friday, March 15, 2002 6:13 AM > I tried, (several times) ... > > Messages stop during boot at: > > calibrating APIC timer ... > ..... cpu clock speed is 1296.0977 Mhz > ..... host bus clock speed is 0.0000 Mhz > cpu: 0, clocks: 0, slice: 0 > > There is no output after the last 0 above. The machine hangs until hard > reset (CTRL+ALT+DEL has no effect). the apic is enabled but the timer counter does not decount :/ > Any hints ? ChangeLog-2.4.14 .... pre4: - Mikael Pettersson: fix P4 boot with APIC enabled perhaps upgrading to 2.4.14 will help. regards, Philippe Elie |