960300 - Copy .lldbinit and friends to the objdir

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[(no longer active)]

So that things such as ./mach mochitest-plain -d lldb pick it up.

Comment 1

[Cameron McCormack (:heycam)]

Attachment: patch

OK, I have no idea how to make the build system do what I want.  Here's the change to .lldbinit that we probably need.  I want it to be preprocessed so that the @TOPSRCDIR@ gets replaced with the actual directory, and to be written out to objdir/.lldbinit.  Hints on how to achieve this appreciated! :)

Comment 2

[Mike Hommey [:glandium]]

.lldbinit is already installed in dist/bin from build/Makefile.in

Comment 3

[Cameron McCormack (:heycam)]

|./mach mochitest-plain -d lldb| runs the debugger with the cwd set to the objdir, though, and that's where lldb is going to look.

Comment 4

[(no longer active)]

I'm not sure how to make things preprocessed in the build system...  Asking info from the build system guys.

For copying it to the objdir, you can do something like <http://mxr.mozilla.org/mozilla-central/source/build/Makefile.in#50>, but setting the _DEST variable to the objdir.

Comment 5

[Michael Shal [:mshal]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #4)
> I'm not sure how to make things preprocessed in the build system...  Asking
> info from the build system guys.
> 
> For copying it to the objdir, you can do something like
> <http://mxr.mozilla.org/mozilla-central/source/build/Makefile.in#50>, but
> setting the _DEST variable to the objdir.

I think you'll want something like this:

diff --git a/build/Makefile.in b/build/Makefile.in
index f75666f..ef7b9c7 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -52,9 +52,10 @@ INSTALL_TARGETS += GDBINIT
 # directory.
 # NOTE: Keep .lldbinit in the topsrcdir for people who run LLDB from the
 # topsrcdir rather than the bin directory.
-LLDBINIT_FILES := $(topsrcdir)/.lldbinit
-LLDBINIT_DEST = $(FINAL_TARGET)
-INSTALL_TARGETS += LLDBINIT
+LLDBINIT := $(topsrcdir)/.lldbinit
+LLDBINIT_PATH = $(DEPTH)
+LLDBINIT_FLAGS += -DTOPSRCDIR=$(abspath $(topsrcdir))
+PP_TARGETS += LLDBINIT
 
 include $(topsrcdir)/config/rules.mk

That will put it at the top-level of the objdir and run the pre-processor on it (adding TOPSRCDIR to the defines).

In order to actually get the variable substitutions to apply, you'll need to add this to the source .lldbinit file (maybe on the 2nd line) -

#filter substitution

Comment 6

[Michael Shal [:mshal]]

Also, for consistency with other pre-processed files, you may want to use @topsrcdir@ rather than @TOPSRCDIR@. See js/src/{jsapi-tests, gdb, shell} and toolkit/library for examples.

Comment 7

[Cameron McCormack (:heycam)]

Attachment: patch v2

Thanks for that info mshal.  For the life of me, I couldn't get the PP_TARGETS approach working in build/Makefile.in (or Makefile.in).  Adding a rule to invoke the preprocessor manually works OK though.

Comment 8

[Mike Hommey [:glandium]]

Comment on attachment 8361399 [details] [diff] [review]
patch v2

Review of attachment 8361399 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/Makefile.in
@@ +53,5 @@
>  # NOTE: Keep .lldbinit in the topsrcdir for people who run LLDB from the
>  # topsrcdir rather than the bin directory.
> +$(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit: $(topsrcdir)/.lldbinit
> +	$(call py_action,preprocessor,-Dtopsrcdir=$(topsrcdir) $< -o $(DEPTH)/.lldbinit)
> +	cp $(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit

Mmmmm, really, I don't believe you can't make that work with PP_TARGETS. That being said, I'd rather find a way not to have to preprocess it at all.
If it's possible to know the path to the .lldbinit file from within, then we can "easily" make it to the topsrcdir. Now the question is: is there? For instance, what does __file__ contain in that script?

@@ +54,5 @@
>  # topsrcdir rather than the bin directory.
> +$(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit: $(topsrcdir)/.lldbinit
> +	$(call py_action,preprocessor,-Dtopsrcdir=$(topsrcdir) $< -o $(DEPTH)/.lldbinit)
> +	cp $(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit
> +libs:: $(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit

Why do you need it at both locations?

Comment 9

[Cameron McCormack (:heycam)]

(In reply to Mike Hommey [:glandium] from comment #8)
> Mmmmm, really, I don't believe you can't make that work with PP_TARGETS.

I just tried the recipe from comment 5 in both build/Makefile.in and in Makefile.in, and neither got invoked.  I don't really know how to debug the build system properly to find out why not.

> That being said, I'd rather find a way not to have to preprocess it at all.
> If it's possible to know the path to the .lldbinit file from within, then we
> can "easily" make it to the topsrcdir. Now the question is: is there? For
> instance, what does __file__ contain in that script?

__file__ is not defined, presumably because it's not a whole external Python file, but just passed to the interpreter internally by lldb when it encounters the "script" command.

The other option would be to search up the tree for ../python/lldbutils/, ../../python/lldbutils/, etc., but that assumes the objdir is somewhere within topsrcdir.

> @@ +54,5 @@
> >  # topsrcdir rather than the bin directory.
> > +$(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit: $(topsrcdir)/.lldbinit
> > +	$(call py_action,preprocessor,-Dtopsrcdir=$(topsrcdir) $< -o $(DEPTH)/.lldbinit)
> > +	cp $(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit
> > +libs:: $(DEPTH)/.lldbinit $(FINAL_TARGET)/.lldbinit
> 
> Why do you need it at both locations?

This is to support people running lldb directly from dist/NightlyDebug.app/Content/MacOS or dist/bin.  I assume people are doing that as the current .lldbinit rules are set up to $(INSTALL) it there.

Comment 10

[Mike Hommey [:glandium]]

Wait, so .lldbinit only works in the current working directory?

Comment 11

[Cameron McCormack (:heycam)]

Yep. Or ~/.lldbinit.

Comment 12

[Michael Shal [:mshal]]

Attachment: pp-targets-example.patch

Attaching the patch I tried - I get a pre-processed .lldbinit in the top-level of the objdir:

$ cat obj-x86_64-unknown-linux-gnu/.lldbinit
...
script path = "python/lldbutils"; sys.path.append(os.path.join("/home/marf/mozilla-central-git", path) if not "/home/marf/mozilla-central-git".startswith("@") else path); import lldbutils; lldbutils.init()
...

If that isn't working for you, feel free to ping me in #build and hopefully we can sort it out.

Comment 13

[Gregory Szorc [:gps]]

Can't we just make |mach debug| do this?

Comment 14

[(no longer active)]

(In reply to comment #13)
> Can't we just make |mach debug| do this?

That would only address some of the cases.  There is also -d which is passed to things such as mochitest-plain, and of course running lldb manually.

Comment 15

[Cameron McCormack (:heycam)]

Attachment: patch v3

Thanks again mshal.  I must have been doing something wrong before, but who knows what.

So I've reorganised things so that the preprocessed file is very small -- it just sets topsrcdir and loads topsrcdir/.lldbinit.  That way if somebody edits topsrcdir/.lldbinit they don't need to rebuild before doing a |mach reftest -d lldb|.  I made objdir/dist/bin/.lldbinit be a symlink to objdir/.lldbinit.

Comment 16

[Mike Hommey [:glandium]]

Comment on attachment 8362031 [details] [diff] [review]
patch v3

Review of attachment 8362031 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/Makefile.in
@@ +48,5 @@
>  INSTALL_TARGETS += GDBINIT
>  
> +# Put a .lldbinit in the bin directory and the objdir, to be picked up
> +# automatically by LLDB when we debug executables using either of those two
> +# directories as the current working diectory.  The .lldbinit file will

directory

Comment 17

[Cameron McCormack (:heycam)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/148382c24e1c

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/148382c24e1c