Project

General

Profile

Actions

Bug #789

closed

LDV-Git doesn't detect call-graph dependencies

Added by Pavel Shved almost 14 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
LDV-Git
Start date:
02/04/2011
Due date:
% Done:

0%

Estimated time:
Detected in build:
91f05e40
Platform:
Published in build:
8038062

Description

After reviewing metadata of Eugene Novikov's machine, I noticed that they don't contain dependency data at all.

Perhaps, the reason is a compiler-specific way of printing those debug dumps, out of which the dependencies are extracted. GCC 4.4.1 on my machine provides the dumps that can be understood by LDV-Git.

Eugene, could you, please, post your version of GCC compiler, and attach a debug dump (on my machine it's named hello_world.c.128r.expand) that is produced by compiling a simple hello_world program (attached):

gcc -o hello_world.o hello_world.c -fdump-rtl-expand

Files

hello_world.c (147 Bytes) hello_world.c hello world program to check debug dump validity Pavel Shved, 02/04/2011 03:59 PM
hello_world.c.145r.expand (4.02 KB) hello_world.c.145r.expand Evgeny Novikov, 02/04/2011 04:14 PM

Related issues 1 (0 open1 closed)

Related to C Instrumentation Framework - Bug #749: Alias Collision on 'init_module'ClosedEvgeny Novikov01/28/2011

Actions
Actions #1

Updated by Evgeny Novikov almost 14 years ago

On my machine it has another name (see attachment).

Actions #2

Updated by Evgeny Novikov almost 14 years ago

I can advice you to try the following command:

gcc -o hello_world.o hello_world.c -fdump-tree-all

may be you'll find something interesting.

Actions #3

Updated by Evgeny Novikov almost 14 years ago

O! I have found a good option for you: -fdump-final-insns[=file] By means of it you can get almost the same as you got (most probably) and control where to dump representation.

Actions #4

Updated by Pavel Shved almost 14 years ago

  • Status changed from Feedback to Open

Newer GCC versions place the dump into the directory where source file resides, while older versions placed it into the current working dir.

I fixed the meta1 script to look for *.expand file in both locations. The fix is placed to fix-789 branch for testing.

Actions #5

Updated by Pavel Shved almost 14 years ago

  • Status changed from Open to Resolved
  • Published in build set to 8038062

Eugene reports that the commit fixes the absence of dependencies.

The fix is merges in 8038062

Actions #6

Updated by Alexey Khoroshilov almost 14 years ago

Are we ready to close it now?

Actions #7

Updated by Pavel Shved almost 14 years ago

Eugene, does it work on your machine as of today? If it does, the bug is closed.

Actions #8

Updated by Evgeny Novikov almost 14 years ago

I'll see it tomorrow or in the day after tomorrow.

Actions #9

Updated by Evgeny Novikov almost 14 years ago

I'll try to test it with the problem described in #749.

Actions #10

Updated by Evgeny Novikov almost 14 years ago

  • Status changed from Resolved to Closed

I observe that dependencies are collected well even more two files were caught in comparison with the listed in #749 ones:

/drivers/base/power/runtime.o 
/drivers/base/devtmpfs.o

Actions

Also available in: Atom PDF