V2 [PATCH] Update check for working assembler --gdwarf-4 option

[H.J. Lu]

On Sat, Oct 17, 2020 at 6:23 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Oct 16, 2020 at 11:29 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Oct 16, 2020 at 11:17 AM Jakub Jelinek <jakub@redhat.com> wrote:
> > >
> > > On Fri, Oct 16, 2020 at 10:58:34AM -0700, H.J. Lu wrote:
> > > > Don't set HAVE_AS_GDWARF_5_DEBUG_FLAG nor HAVE_AS_WORKING_DWARF_4_FLAG
> > > > if there is an extra assembly input file in debug info generated by
> > > > --gdwarf-5/--gdwarf-4:
> > > >
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=25878
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26740
> > > >
> > > > Also replace success with dwarf4_success in the 32-bit --gdwarf-4 check.
> > > >
> > > > OK for master?
> > > >
> > > >       PR bootstrap/97451
> > > >       * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG): Don't define if
> > > >       there is an extra assembly input file in debug info.
> > > >       (HAVE_AS_WORKING_DWARF_4_FLAG): Likewise.  Replace success with
> > > >       dwarf4_success in the 32-bit --gdwarf-4 check.
> > > >       * configure: Regenerated.
> > >
> > > The HAVE_AS_GDWARF_5_DEBUG_FLAG macro should be solely about whether
> > > -gdwarf-5 can be passed to as, nothing else.  That is because it is not only
> > > used to decide if we can pass -gdwarf-5 to as for assembly of e.g. *.c
> > > compilation, but also if we can pass it to as when gcc driver is invoked on
> > > *.s and *.S.  And in that case the problems with -gdwarf-N having unwanted
> > > effects on assembly with compiler generated .debug_info etc. sections.
> > > don't really matter.
> > >
> > > The HAVE_AS_WORKING_DWARF_4_FLAG perhaps could be renamed to
> > > ...DWARF_N_FLAG, it is meant to check for whether we can safely pass the
> > > option also for *.c etc. compilation when we emit debug info sections by the
> > > compiler.
> > >
> > > For that, the question is, are all the issues already fixed on the binutils
> > > trunk?  As in, do I get identical object files e.g. for -gdwarf-2
> >
> > Not yet.  This patch:
> >
> > https://sourceware.org/pipermail/binutils/2020-October/113744.html
> >
> > is needed for binutils master branch.  BTW, binutils 2.35 and 2.35.1 are
> > broken.
> >
> > > compilation no matter whether the compiler passes -gdwarf-2 to gas or not
> > > (assuming dwarf 2 is the default in gas) when compiling various *.c/*.C
> > > files?  Ditto for modified gas that would default to other .debug_line
> > > versions and corresponding gcc -gdwarf-N flag and passing vs. not passing
> > > that -gdwarf-N to gas?
> > >
> > > The hope is that -gdwarf-N to gas would have two functions:
> > > 1) if the assembly doesn't contain .debug* sections/.file/.loc directives,
> > >    emit debug info (mainly .debug_line) for the assembler file in order to
> > >    be able to debug those
> > > 2) if the assembly does contain .debug* sections/.file/.loc directives,
> > >    only change the version of the .debug_line generated for the .file/.loc
> > >    directives, but nothing else; keep all .debug* sections but .debug_line
> > >    as is
> >
>
> Here is the updated patch.  OK for master?
>

The updated patch to check

https://sourceware.org/bugzilla/show_bug.cgi?id=26778

OK for master?


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-check-for-working-assembler-gdwarf-4-option.patch
Type: text/x-patch
Size: 10269 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201024/81bc1bdd/attachment.bin>