Copy .lldbinit and friends to the objdir

RESOLVED FIXED in mozilla29

Status

defect
RESOLVED FIXED
6 years ago
Last year

People

(Reporter: Ehsan, Assigned: heycam)

Tracking

Trunk
mozilla29
x86
macOS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

Reporter

Description

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

Comment 1

6 years ago
Posted patch patch (obsolete) — Splinter Review
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! :)
Flags: needinfo?(ehsan)
.lldbinit is already installed in dist/bin from build/Makefile.in
Assignee

Comment 3

6 years ago
|./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.
Reporter

Comment 4

6 years ago
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.
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gps)
Flags: needinfo?(ehsan)
(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
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.
Assignee

Comment 7

6 years ago
Posted patch patch v2 (obsolete) — Splinter Review
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.
Attachment #8360946 - Attachment is obsolete: true
Attachment #8361399 - Flags: review?(mh+mozilla)
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gps)
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?
Attachment #8361399 - Flags: review?(mh+mozilla) → review-
Assignee

Comment 9

6 years ago
(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.
Wait, so .lldbinit only works in the current working directory?
Assignee

Comment 11

6 years ago
Yep. Or ~/.lldbinit.
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.
Flags: needinfo?(cam)
Can't we just make |mach debug| do this?
Reporter

Comment 14

6 years ago
(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.
Assignee

Comment 15

6 years ago
Posted patch patch v3Splinter Review
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.
Attachment #8361399 - Attachment is obsolete: true
Attachment #8362031 - Flags: review?(mh+mozilla)
Flags: needinfo?(cam)
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
Attachment #8362031 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/148382c24e1c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29

Updated

Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.