building with debug information in a variant

[Alexandre Cossette]

Hi!

I'm trying to make a debug variant that would build with debug information. However, since the source are compiled from the build-debug directory, it does not seem to work. If I understand correctly, this is because the source tree is mirrored inside the variant directory with the fuse file system and I guess my debug information contains references to these fake files. Is there a recommended way to make it work?

Alex

[Mike Shal]

Hi Alex,

What compiler flags and debugging tools are you using? If it's just
the fuse path (ie: /home/foo/project/.tup/mnt/home/foo/project/src
instead of /home/foo/project/src) that is causing problems, it may
help to run it the sub-process in a chroot (using the 'c' ^-flag).
This way gcc doesn't really know that it's running inside fuse and
won't see the extra path. However with variants, tup is still doing an
overlay so that build-debug/src and src/ appear as a unified tree, so
if it's the build-debug path that is causing problems, I will probably
need to look at it in more detail (the command-line you're using will
help me here :)

Thanks,
-Mike

[Slawomir Czarko]

Try to pass -fdebug-prefix-map option to gcc. In my bash build script I have:

shopt -s extglob

DEBUG_PREFIX=${PWD##*@tupjob-+([0-9])}

g++ -fdebug-prefix-map=${PWD}=${DEBUG_PREFIX} ...

- Slawomir

[Alexandre Cossette]

Hi Mike,

I compile on Mac OS X 10.8. I do use the ^c^ flag. A very basic Tupfile reproduces the problem:

: foreach *.cpp |> ^c^ cc -g -c %f -o %o |> %B.o

: *.o |> ^c^ cc %f -o %o |> testtup

I did some more experiments and I discovered that if I run gdb from the source directory (instead of from build-debug), it works fine. I still think that it would be better if tup passed a path for %f that is relative to the build-debug directory (for example ../testtup.cpp) instead of faking that the source files are in there. This way, if I have some generated source files within the build directory, I could use these in a debugging session together with the main sources.

[BB]

I worked through this problem for my own project this morning.  I'm building various .a files with a Tupfile in each directory, then linking them with application code in another directory with it's own Tupfile.  All of this going to a single variant directory at the top of the tree...

What I had to do was use sed to convert the FUSE pwd under .tup to the actual directory where the source lives and combine that with gcc's -fdebug-prefix-map option...

I had to create an @-variable in my variant's tup.config file:

CONFIG_FILEPATH=`pwd|sed 's/.*tupjob-[0-9]*\(.*\)/\1/'|sed 's:build_default/::'`

(my variant is called build_default, which you can see is encoded in the 2nd use of sed)

Then I changed my !cc rules:

!cc = |> ^ CC %f^ $(CC) -fdebug-prefix-map=`pwd`=@(FILEPATH) @(VAR_CFLAGS) -c `pwd`/%f -o %o $(CFLAGS) $(CFLAGS_%f) |> %B.o

Now all of my .o files are compiled with the fullpath to the source so that gdb can find the source regardless of where I move the compiled binary.

Enjoy!

Britt

[Mike Shal]

On Sun, Sep 2, 2012 at 5:05 PM, Alexandre Cossette
<alex.c...@gmail.com> wrote:
> Hi Mike,
>
> I compile on Mac OS X 10.8. I do use the ^c^ flag. A very basic Tupfile
> reproduces the problem:
>
> : foreach *.cpp |> ^c^ cc -g -c %f -o %o |> %B.o
>
> : *.o |> ^c^ cc %f -o %o |> testtup
>
> I did some more experiments and I discovered that if I run gdb from the
> source directory (instead of from build-debug), it works fine. I still think
> that it would be better if tup passed a path for %f that is relative to the
> build-debug directory (for example ../testtup.cpp) instead of faking that
> the source files are in there. This way, if I have some generated source
> files within the build directory, I could use these in a debugging session
> together with the main sources.
>

I don't think adjusting %f would necessarily fix it. Consider if there
is a generated header file in the same directory, then #include
"foo.h" will be looking in the src tree rather than in the build tree,
so it wouldn't find the file.

It may help if tup runs the gcc process in the src tree directly and
then uses the build tree as the backup (whereas now it runs gcc in the
build tree and uses the src tree as a backup). I'll have to give that
a try though...

-Mike

[Mike Shal]

On Wed, Sep 5, 2012 at 5:59 PM, BB <britt...@gmail.com> wrote:
> I worked through this problem for my own project this morning. I'm building
> various .a files with a Tupfile in each directory, then linking them with
> application code in another directory with it's own Tupfile. All of this
> going to a single variant directory at the top of the tree...
>
> What I had to do was use sed to convert the FUSE pwd under .tup to the
> actual directory where the source lives and combine that with gcc's
> -fdebug-prefix-map option...
>
> I had to create an @-variable in my variant's tup.config file:
>
> CONFIG_FILEPATH=`pwd|sed 's/.*tupjob-[0-9]*\(.*\)/\1/'|sed
> 's:build_default/::'`
>
> (my variant is called build_default, which you can see is encoded in the 2nd
> use of sed)
>
> Then I changed my !cc rules:
>
> !cc = |> ^ CC %f^ $(CC) -fdebug-prefix-map=`pwd`=@(FILEPATH) @(VAR_CFLAGS)
> -c `pwd`/%f -o %o $(CFLAGS) $(CFLAGS_%f) |> %B.o
>
> Now all of my .o files are compiled with the fullpath to the source so that
> gdb can find the source regardless of where I move the compiled binary.
>
> Enjoy!
>
> Britt

That is... inventive :). Definitely makes me realize that the current
implementation of variants is not ideal. It is supposed to be as
simple as specifying "-O2" in one config file and "-g" in another so
you get an optimized build in one directory and a debug build in
another. Having to add all this extra stuff for the debug build is a
failure in tup...

-Mike

[Alexandre Cossette]

I think that, when calling tools for a variant, tup should not hide that there are 2 directories involved. This way, it would support all the tools that consider not only the content but also the location of the files specified as input. In addition, I think it would simplify porting tup to platforms that does not support fuse...

In the case of the generated header file, adding something like -I$(VARIANT_DIR) to the compiler flags would do the trick.

Alex