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

Handle -g0 properly #371

Merged
merged 1 commit into from Apr 2, 2019
Merged

Handle -g0 properly #371

merged 1 commit into from Apr 2, 2019

Conversation

pavsa
Copy link
Contributor

@pavsa pavsa commented Apr 2, 2019

Solves #368

I have reused testing in depend mode as it has ideal setup this would fail.

Also removed the depend_different_headers.bash due to not being needed anymore.

@jrosdahl jrosdahl merged commit afa4eea into ccache:master Apr 2, 2019
jrosdahl added a commit that referenced this pull request Apr 2, 2019
jrosdahl added a commit that referenced this pull request Apr 2, 2019
@jrosdahl
Copy link
Member

jrosdahl commented Apr 2, 2019

Oops, I was too fast merging this. And GitHub annoyingly doesn't allow me to reopen the pull request after reverting. 🙁

@@ -2634,6 +2634,11 @@ cc_process_args(struct args *args, struct args **preprocessor_args,

// Debugging is handled specially, so that we know if we can strip line
// number info.
if (str_eq(argv[i], "-g0")) {
Copy link
Member

Choose a reason for hiding this comment

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

This is not quite enough since -g3 -g0 still will enter the if statement below and for instance set conf->run_second_cpp = true.

And more importantly: since -g0 isn't added to stripped_args it won't be sent to the compiler so the compiler will then use -g3.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, there's also another problem with:

  1. conf->unify = true
  2. -g1 was parsed and conf->unify was set to false
  3. -g0 was parsed, but we can't restore conf->unify back to true, as there is no information of state of conf->unify before the -g1 caused it to be set to false

How do we solve this?

Copy link
Member

Choose a reason for hiding this comment

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

Right. Thinking more about this, I now remember that we used to have smarter processing of -g* options (#92) but it was reverted (b8aeb98) due to being buggy (#149).

The best solution I see is to remember the last -g* option and only act (maybe disable unify, maybe set , etc.) after we have looped over all arguments. But it is quite complex to figure out how all options interact, so it's not clear to me how that should be implemented. For instance, -ggdb3 -g0 seems to be equivalent to -g3 -ggdb0, but -ggdb3 -g2 is not equivalent to -g3 -ggdb2...

So maybe we should keep things safe and not try to handle -g3 -g0 like I suggested. We could still handle the simple case in #368 like you did, but the argument then needs to be added to stripped_args.

Hmm... It does seem like -g*0 disables all debug info enabled by previous options, though, so maybe we could make use of that fact. I made an attempt in 749fa11 on a separate branch. What do you think about that approach?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks good to me. Will you push it?

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for having a look. I'll push it after writing some tests.

@@ -78,7 +78,7 @@ EOF
backdate "$BASEDIR3/header.h" "$BASEDIR3/test.c"
backdate "$BASEDIR4/header.h" "$BASEDIR4/test.c" "$BASEDIR4/header2.h"

DEPFLAGS="-MD -MF test.d"
DEPFLAGS="-g1 -g0 -MD -MF test.d"
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer a separate test case for this (in the base suite) to make it possible to understand to purpose of the flags.

@jrosdahl
Copy link
Member

jrosdahl commented Apr 2, 2019

@pavsa: I don't know if you got mail about my review comments since the PR has been closed already, so here's an extra ping that I left some feedback.

pavsa added a commit to pavsa/ccache that referenced this pull request Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants