4

I'm trying to get debugging metadata from an llvm Instruction using the DILocation class.

However, when I query the DILocation for the filename where the instruction came from, I get a filename with a directory tagged onto the front.

I though it would return just the file and the entire directory path should be retrieved via a call to getDirectory().

For example, instead of XMain_0.c I end up with pbg/XMain_0.c

I compiled my bitcode like this:

XMain_0.o: pbg/XMain_0.c
    $(CC) <snip> -c pbg/XMain_0.c

Does the fact that I passed in my source with a directory on it mean that the metadata saves the source filename as the input?

Here's a cut down example:

  const llvm::Instruction* inst  //passed in
  MDNode *n = inst->getMetadata("dbg");
  DILocation loc(n);  

  file = loc.getFilename().str(); // =>  pbg/XMain_0.c
  dir = loc.getDirectory().str(); // => /projects/pbg/pbg-m/DIR

Are there calls I can make to "normalize" this data or do I need to do it by hand?

Clang 3.1 if that matters.

Paul Rubel
  • 26,632
  • 7
  • 60
  • 80

1 Answers1

3

I think it depends on the invocation of the compiler. If you run:

clang -c somedir/somefile.c

Then the full somedir/somefile.c will be the filename.

How does your invocation look like?

There is nothing weird about it. The debugger will look for source files relative to some project root, and if you compile files likes this, it's the way they are going to be found. gcc does the same thing:

/tmp$ pwd
/tmp
/tmp$ cat subdir/test.c 
int foo() {
  return 42;
}

/tmp$ gcc -g -O0 -c subdir/test.c -o test.o
/tmp$ readelf --debug-dump=info test.o | grep -A4 compile_unit
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x0): GNU C 4.6.3   
    <10>   DW_AT_language    : 1    (ANSI C)
    <11>   DW_AT_name        : (indirect string, offset: 0xc): subdir/test.c    
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x1a): /tmp
Eli Bendersky
  • 263,248
  • 89
  • 350
  • 412
  • As you can see in the Makefile above, I did compile as you noted, giving it a subdirectory and the file. The behavior just seems odd. – Paul Rubel Jan 07 '13 at 17:34
  • I can see how this decision is helpful to debugger writers, but thinking over this for the past day it does seem that getFilename() is somewhat misleadingly named. I can live with the current situation, and I'm not sure what a better name is, but in a perfect world it seems that there would be another call, something like getFilenameRelativeToProjectPath() that would do what getFilename currently does. Oh Well. – Paul Rubel Jan 08 '13 at 16:42
  • @PaulRubel: IIRC this is consistent with the DWARF standard – Eli Bendersky Jan 08 '13 at 17:56