Re: [PATCH] Fix DJGPP LTO with debug
On 07/31/2018 04:04 PM, Richard Biener wrote: On Sat, 28 Jul 2018, Andris Pavenis wrote: On 07/27/2018 11:51 PM, DJ Delorie wrote: Richard Biener writes: DJ, did you ever run the testsuite with a configuration that has LTO enabled? I don't see any djgpp results posted to gcc-testresults. Quick googling doesn't yield anything useful with regarding on how to do actual testing with a cross so I only built a i686-pc-msdosdjgpp cross cc1/lto1 from x86_64-linux which went fine. CC's Andris, our current gcc maintainer within DJGPP. I know he just built 8.2 binaries for us, I don't know what his testing infrastructure looks like. No. II tried to run part of tests from custom scripts (eg. when trying to implement DJGPP support for libstdc++fs, not yet submitted to upstream) with native compiler for DJGPP. Otherwise no DejaGNU support for DJGPP. So no way to run testsuite with native compiler. I should perhaps try to find some way to try to run testsuite using cross-compiler from Linux. Possibilities: - trying to execute test programs under DosEmu (no more possible with linux kernels 4.15+ as DosEmu do not support DPMI for them) - trying to execute test programs under Dosbox. Question: how to configure testsuiite to do that? I do not know - trying to run them through ssh on some Windows 32 bit system (older than Windows 10 as DPMI support is rather horribly broken in Windows 10 32 bit since March 2018) So what about the patch? Is it OK for trunk and GCC 8 branch? It is OK for both (actually tested with gcc-8.2.0). I comments about patch together with results of performed tests can be found in Bugzilla https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 Andris
Re: [PATCH] Fix DJGPP LTO with debug
On Sat, 28 Jul 2018, Andris Pavenis wrote: > On 07/27/2018 11:51 PM, DJ Delorie wrote: > > Richard Biener writes: > > > DJ, did you ever run the testsuite with a configuration that has LTO > > > enabled? I don't see any djgpp results posted to gcc-testresults. > > > Quick googling doesn't yield anything useful with regarding on how to > > > do actual testing with a cross so I only built a i686-pc-msdosdjgpp > > > cross cc1/lto1 from x86_64-linux which went fine. > > CC's Andris, our current gcc maintainer within DJGPP. I know he just > > built 8.2 binaries for us, I don't know what his testing infrastructure > > looks like. > > > No. > > II tried to run part of tests from custom scripts (eg. when trying to > implement DJGPP support for libstdc++fs, not yet submitted to upstream) with > native compiler for DJGPP. > > Otherwise no DejaGNU support for DJGPP. So no way to run testsuite with native > compiler. > > I should perhaps try to find some way to try to run testsuite using > cross-compiler from Linux. Possibilities: > - trying to execute test programs under DosEmu (no more possible with linux > kernels 4.15+ as DosEmu do not support DPMI for them) > - trying to execute test programs under Dosbox. Question: how to configure > testsuiite to do that? I do not know > - trying to run them through ssh on some Windows 32 bit system (older than > Windows 10 as DPMI support is rather horribly broken in Windows 10 32 bit > since March 2018) So what about the patch? Is it OK for trunk and GCC 8 branch? Thanks, Richard.
Re: [PATCH] Fix DJGPP LTO with debug
On 07/27/2018 11:51 PM, DJ Delorie wrote: Richard Biener writes: DJ, did you ever run the testsuite with a configuration that has LTO enabled? I don't see any djgpp results posted to gcc-testresults. Quick googling doesn't yield anything useful with regarding on how to do actual testing with a cross so I only built a i686-pc-msdosdjgpp cross cc1/lto1 from x86_64-linux which went fine. CC's Andris, our current gcc maintainer within DJGPP. I know he just built 8.2 binaries for us, I don't know what his testing infrastructure looks like. No. II tried to run part of tests from custom scripts (eg. when trying to implement DJGPP support for libstdc++fs, not yet submitted to upstream) with native compiler for DJGPP. Otherwise no DejaGNU support for DJGPP. So no way to run testsuite with native compiler. I should perhaps try to find some way to try to run testsuite using cross-compiler from Linux. Possibilities: - trying to execute test programs under DosEmu (no more possible with linux kernels 4.15+ as DosEmu do not support DPMI for them) - trying to execute test programs under Dosbox. Question: how to configure testsuiite to do that? I do not know - trying to run them through ssh on some Windows 32 bit system (older than Windows 10 as DPMI support is rather horribly broken in Windows 10 32 bit since March 2018) Andris
Re: [PATCH] Fix DJGPP LTO with debug
Richard Biener writes: > DJ, did you ever run the testsuite with a configuration that has LTO > enabled? I don't see any djgpp results posted to gcc-testresults. > Quick googling doesn't yield anything useful with regarding on how to > do actual testing with a cross so I only built a i686-pc-msdosdjgpp > cross cc1/lto1 from x86_64-linux which went fine. CC's Andris, our current gcc maintainer within DJGPP. I know he just built 8.2 binaries for us, I don't know what his testing infrastructure looks like.
[PATCH] Fix DJGPP LTO with debug
This patch from jwjager...@gmail.com clones the fixes done for
mingw and darwin to make LTO work together with -g in GCC 8+.
It's said to build OK in a djgpp configuration and I expect similar
results as for mingw and darwin.
The original application the reporter ran into the issue with isn't
fixed because of latent issues when combining a -g0 compile with
a -g link (the default for those targets).
Bootstrapped on x86_64-unknown-linux-gnu, ok for trunk and GCC 8 branch?
DJ, did you ever run the testsuite with a configuration that has LTO
enabled? I don't see any djgpp results posted to gcc-testresults.
Quick googling doesn't yield anything useful with regarding on how to
do actual testing with a cross so I only built a i686-pc-msdosdjgpp
cross cc1/lto1 from x86_64-linux which went fine.
Thanks,
Richard.
2018-07-27 Jan Willem Jagersma
PR target/86651
* dwarf2out.c (dwarf2out_early_finish): Do not generate assembly in LTO
mode for COFF targets.
* defaults.h (TARGET_COFF): Define.
* config/i386/djgpp.h (TARGET_ASM_LTO_START, TARGET_ASM_LTO_END,
TARGET_COFF): Define.
(i386_djgpp_asm_lto_start, i386_djgpp_asm_lto_end): Declare.
* config/i386/djgpp.c (saved_debug_info_level): New static variable.
(i386_djgpp_asm_lto_start, i386_djgpp_asm_lto_end): New functions.
diff --git a/gcc/config/i386/djgpp.c b/gcc/config/i386/djgpp.c
index f168eed6f06..d187c3a7452 100644
--- a/gcc/config/i386/djgpp.c
+++ b/gcc/config/i386/djgpp.c
@@ -47,3 +47,20 @@ i386_djgpp_asm_named_section(const char *name, unsigned int
flags,
fprintf (asm_out_file, "\t.section\t%s,\"%s\"\n", name, flagchars);
}
+
+/* Kludge because of missing COFF support for early LTO debug. */
+
+static enum debug_info_levels saved_debug_info_level;
+
+void
+i386_djgpp_asm_lto_start (void)
+{
+ saved_debug_info_level = debug_info_level;
+ debug_info_level = DINFO_LEVEL_NONE;
+}
+
+void
+i386_djgpp_asm_lto_end (void)
+{
+ debug_info_level = saved_debug_info_level;
+}
diff --git a/gcc/config/i386/djgpp.h b/gcc/config/i386/djgpp.h
index 01774cea4d6..dd8c71b833a 100644
--- a/gcc/config/i386/djgpp.h
+++ b/gcc/config/i386/djgpp.h
@@ -157,8 +157,19 @@ along with GCC; see the file COPYING3. If not see
#undef MAKE_DECL_ONE_ONLY
#define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) = 1)
+#undef TARGET_COFF
+#define TARGET_COFF 1
+
+/* Kludge because of missing COFF support for early LTO debug. */
+#undef TARGET_ASM_LTO_START
+#define TARGET_ASM_LTO_START i386_djgpp_asm_lto_start
+#undef TARGET_ASM_LTO_END
+#define TARGET_ASM_LTO_END i386_djgpp_asm_lto_end
+
/* Function protypes for gcc/i386/djgpp.c */
void
i386_djgpp_asm_named_section(const char *name, unsigned int flags,
tree decl);
+void i386_djgpp_asm_lto_start (void);
+void i386_djgpp_asm_lto_end (void);
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 78a08a33f12..9035b333be8 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -1282,6 +1282,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
#define TARGET_PECOFF 0
#endif
+#ifndef TARGET_COFF
+#define TARGET_COFF 0
+#endif
+
#ifndef EH_RETURN_HANDLER_RTX
#define EH_RETURN_HANDLER_RTX NULL
#endif
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8377cbc5dd1..c75aadbaa2c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31938,10 +31938,10 @@ dwarf2out_early_finish (const char *filename)
/* Do not generate DWARF assembler now when not producing LTO bytecode. */
if ((!flag_generate_lto && !flag_generate_offload)
- /* FIXME: Disable debug info generation for PE-COFF targets since the
+ /* FIXME: Disable debug info generation for (PE-)COFF targets since the
copy_lto_debug_sections operation of the simple object support in
libiberty is not implemented for them yet. */
- || TARGET_PECOFF)
+ || TARGET_PECOFF || TARGET_COFF)
return;
/* Now as we are going to output for LTO initialize sections and labels
