Bug 10727 - can't set file:line breakpoint in ccache/clang compiled source
can't set file:line breakpoint in ccache/clang compiled source
Status: RESOLVED WONTFIX
Product: ccache
Classification: Unclassified
Component: ccache
3.1.9
x64 Mac OS X
: P5 normal
: ---
Assigned To: Joel Rosdahl
Joel Rosdahl
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-18 23:34 UTC by Vince Harron (I'm not checking this email account anymore)
Modified: 2015-08-15 14:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vince Harron (I'm not checking this email account anymore) 2014-07-18 23:34:31 UTC
ccache compiled code has *.i filenames instead of *.c file names so the breakpoint can't be found.

repro steps:

vharron-macbookpro:bp vharron$ cat bp.c
#include <stdio.h>

int
main() {
  printf("Hello, World!\n");
  return 0;
}
vharron-macbookpro:bp vharron$ ./build.sh
+ CCACHE=ccache
+ ccache gcc -g -o bp.o -c bp.c
+ gcc -o bp bp.o
vharron-macbookpro:bp vharron$ lldb bp
Current executable set to 'bp' (x86_64).
(lldb) b bp.c:5

expected output:
Breakpoint 1: where = bp`main + 22 at bp.c:5, address = 0x0000000100000f56
(lldb) r

actual output:
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
[reply] [-] Comment 6

Removing ccache fixes this problem

filename in ccache generated symbols is incorrect?

With ccache:
cu_sp->GetPath().c_str() /Users/vharron/.ccache/tmp/bp.tmp.vharron-macbookpro.roam.corp.google.com.6262.i

Without ccache:
cu_sp->GetPath().c_str() /Users/vharron/dev/bp/bp.c
[reply] [-] Comment 3

LLDB says a fix for this would cause significant performance regressions for the general case:
http://llvm.org/bugs/show_bug.cgi?id=20297

OSX 10.9.4
vharron-macbookpro:bp vharron$ lldb --version
lldb-310.2.37 (also reproduced with head of SVN)
vharron-macbookpro:bp vharron$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
vharron-macbookpro:bp vharron$ ccache --version
ccache version 3.1.9

Copyright (C) 2002-2007 Andrew Tridgell
Copyright (C) 2009-2011 Joel Rosdahl

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 3 of the License, or (at your option) any later
version.
Comment 1 Joel Rosdahl 2014-08-09 09:22:06 UTC
A workaround should be to build with CCACHE_CPP2=1.

> filename in ccache generated symbols is incorrect?

I would say: no. What the compiler compiled was the preprocessed .i file, not the .c file (unless CCACHE_CPP2=1 in which case the compiler compiles the original .c file instead of the intermediary .i file).

> LLDB says a fix for this would cause significant performance regressions
> for the general case: http://llvm.org/bugs/show_bug.cgi?id=20297

Not sure I understand lldb's logic here at a quick glance. Would it work if cu_sp->GetPath().c_str() was "/Users/vharron/.ccache/tmp/bp.tmp.vharron-macbookpro.roam.corp.google.com.6262.c" instead of "/Users/vharron/.ccache/tmp/bp.tmp.vharron-macbookpro.roam.corp.google.com.6262.i" or did have to be "/Users/vharron/dev/bp/bp.c" to work?
Comment 2 Joel Rosdahl 2015-08-15 14:49:16 UTC
Closing due to lack of progress. Please reopen if there are any new feedback on the problem.