Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execute dsymutil on build on macOS #4969

Merged
merged 3 commits into from Sep 14, 2017
Merged

Execute dsymutil on build on macOS #4969

merged 3 commits into from Sep 14, 2017

Conversation

asterite
Copy link
Member

Fixes #4186

I think better output on exceptions is worth it when the cost is just having a .dwarf file sitting next to the executable (and in some cases you don't get to see that file if you run crystal run file.cr or just crystal file.cr).

Adds an option, only on Mac, to disable running dsymutil.

I ran dsymutil on the compiler's executable and it takes about 1 second. I think it's acceptable, given that the compiler is relatively big, so for other projects it will be much less time. And there's always the option to disable this feature.

# Delete related dwarf generated by dsymutil, if any exists
{% if flag?(:darwin) %}
if compiler.generates_dsymutil?
File.delete("#{output_filename}.dwarf") rescue nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe deleting the file should happen even if --no-dsymutil is used.
So after some compilation in debug mode with default options, the next compilation in release (or debug with --no-dsymutil) won't have a misleading dwarf.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

execute is only invoked when you do crystal foo.cr and a temporary executable is created in the cache directory. So in this case I don't see a problem.

For the case where you do crystal build foo.cr and then crystal build foo.cr --no-debug I wouldn't delete the dwarf file because we don't know if we are the ones who generated it in a previous run. And in any case dwarf files have a UUID that relates them with the executable, so an old dwarf file won't cause problems.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙆‍♂️

@@ -298,6 +308,12 @@ class Crystal::Command
opts.on("--no-debug", "Skip any symbolic debug info") do
compiler.debug = Crystal::Debug::None
end

{% if flag?(:darwin) %}
opts.on("--no-dsymutil", "Don't invoke dsymutil") do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't find this description helpful.
Also, why not bunch this together with --no-debug

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because --no-debug makes it impossible to debug with gdb or lldb. But even if passing --no-dsymutil you can debug with gdb or lldb.

But yes, I think we can just remove this option, I don't mind having this dwarf file generated every time.

end

CacheDir.instance.cleanup if @cleanup

result
end

private def run_dsymutil(filename)
`which dsymutil`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may:

return unless Process.find_executable("dsymutil")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow! What a great standard library :-)

@asterite
Copy link
Member Author

I changed it so --no-debug implies not running dsymutil, and removed the --no-dsymutil cryptic option :-)

@sdogruyol
Copy link
Member

LGTM?

@RX14 RX14 added this to the Next milestone Sep 14, 2017
@RX14 RX14 merged commit 429bda3 into crystal-lang:master Sep 14, 2017
@asterite asterite deleted the feature/dsymutil branch September 14, 2017 23:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants