public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
Date: Sat, 04 Dec 2010 10:28:00 -0000	[thread overview]
Message-ID: <bug-46749-4-Y4eIgG7IjF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-46749-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749

--- Comment #34 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-04 10:27:58 UTC ---
On Sat, 4 Dec 2010, mikestump at comcast dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #31 from Mike Stump <mikestump at comcast dot net> 2010-12-04 00:18:07 UTC ---
> On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote:
> > yes, I would have expected that this happens already.  Now, I (or
> > somebody else) needs to take the time and investigate why this
> > doesn't happen.
> 
> Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
> lto temporary files, early.  The below are the files that are too early, and
> will `fix' the issue.
> 
> Index: collect2.c
> ===================================================================
> --- collect2.c    (revision 167409)
> +++ collect2.c    (working copy)
> @@ -1056,7 +1056,9 @@
>        fork_execute ("ld", out_lto_ld_argv);
>        free (lto_ld_argv);
> 
> +#if 0
>        maybe_unlink_list (lto_o_files);
> +#endif
>      }
>    else if (force)
>      {
> 
> If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
> and then we let record_temp_file register _all_ the temporary files, and the
> let gcc.c delete the temporary files at the end, all work work just fine.

Well - yes.  There is the complication called linker-plugin (which
is also removing the files).  You can't fold the linker plugin
(thus, the linker) into the gcc driver.

I thought a long time on what a solution to the problem could be and
only see the following:

 - The GCC driver is the place where we can detect if we need to
   execute dsymutil because we'll only have temporary object files.
   The GCC driver needs to arrange for a new -dsym option being
   passed to the linker (which might be collect2 for example)

 - The _linker_ (or collect2 for example) is responsible for
   invoking dsymutil if there is a -dsym option on the command-line.
   Only at link time we are sure all object files are still around.

If darwin only ever uses collect2 (and not the linker-plugin) then
this would be a easy and localized change.  It would of course also
offer the user to specify that he wants dsymutil to run.

Richard.


  parent reply	other threads:[~2010-12-04 10:28 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01 17:43 [Bug debug/46749] New: " howarth at nitro dot med.uc.edu
2010-12-01 17:50 ` [Bug debug/46749] " howarth at nitro dot med.uc.edu
2010-12-01 18:05 ` howarth at nitro dot med.uc.edu
2010-12-01 18:44 ` rguenth at gcc dot gnu.org
2010-12-01 20:31 ` howarth at nitro dot med.uc.edu
2010-12-01 20:31 ` howarth at nitro dot med.uc.edu
2010-12-01 20:33 ` howarth at nitro dot med.uc.edu
2010-12-01 20:35 ` howarth at nitro dot med.uc.edu
2010-12-01 20:38 ` rguenth at gcc dot gnu.org
2010-12-01 20:46 ` iains at gcc dot gnu.org
2010-12-01 20:50 ` rguenth at gcc dot gnu.org
2010-12-01 20:59 ` howarth at nitro dot med.uc.edu
2010-12-01 21:11 ` iains at gcc dot gnu.org
2010-12-01 21:21 ` iains at gcc dot gnu.org
2010-12-01 21:24 ` rguenth at gcc dot gnu.org
2010-12-01 21:34 ` iains at gcc dot gnu.org
2010-12-01 21:51 ` rguenther at suse dot de
2010-12-01 21:53 ` iains at gcc dot gnu.org
2010-12-01 22:06 ` iains at gcc dot gnu.org
2010-12-02  8:53 ` rguenther at suse dot de
2010-12-02  9:10 ` iains at gcc dot gnu.org
2010-12-02  9:51 ` rguenther at suse dot de
2010-12-02 10:10 ` iains at gcc dot gnu.org
2010-12-02 10:14 ` iains at gcc dot gnu.org
2010-12-03  0:26 ` mrs at gcc dot gnu.org
2010-12-03 10:48 ` rguenther at suse dot de
2010-12-03 10:51 ` rguenther at suse dot de
2010-12-03 11:30 ` iains at gcc dot gnu.org
2010-12-03 12:11 ` iains at gcc dot gnu.org
2010-12-03 23:13 ` mikestump at comcast dot net
2010-12-03 23:21 ` rguenther at suse dot de
2010-12-04  0:18 ` mikestump at comcast dot net
2010-12-04  2:11 ` howarth at nitro dot med.uc.edu
2010-12-04  3:19 ` howarth at nitro dot med.uc.edu
2010-12-04 10:28 ` rguenther at suse dot de [this message]
2010-12-05 21:13 ` mikestump at comcast dot net
2010-12-05 21:57 ` rguenth at gcc dot gnu.org
2010-12-07  0:26 ` mrs at gcc dot gnu.org
2010-12-07  0:34 ` mrs at gcc dot gnu.org
2010-12-07  9:47 ` rguenth at gcc dot gnu.org
2010-12-07 13:21 ` joseph at codesourcery dot com
2010-12-07 16:34 ` mrs at gcc dot gnu.org
2010-12-07 16:42 ` mikestump at comcast dot net
2010-12-08 20:11 ` mrs at gcc dot gnu.org
2010-12-08 23:13 ` mrs at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-46749-4-Y4eIgG7IjF@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).