[v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html
Changes v3->v4:
- Only patch 2 (DWARF generation) is changed; update based on Richard's
review comments.
- Fix an issue with generating DWARF for type_tags when a typedef involves
type_tags and the use of the
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF
The expected macro debug information is not issued with
-gstrict-dwarf, and ports such as vxworks default to that. Allow
non-strict dwarf for the test.
Tested with gcc-14 targeting ppc-vx7r2 and ppc64-vx7r2. Also tested
with trunk on ppc64le-linux-gnu, and with gcc-14 targeting powerpc-elf
e strings are recorded in debug information for
> >>>> post-compilation uses, and despite the name they are meant to be
> >>>> recorded in DWARF as well as BTF. New DWARF extensions
> >>>> DW_TAG_GNU_annotation and DW_AT_GNU_annotation are used to re
_tag and btf_type_tag attributes provide a means to annotate
>>>> declarations and types respectively with arbitrary user provided
>>>> strings. These strings are recorded in debug information for
>>>> post-compilation uses, and despite the name they are meant t
ns and types respectively with arbitrary user provided
> >> strings. These strings are recorded in debug information for
> >> post-compilation uses, and despite the name they are meant to be
> >> recorded in DWARF as well as BTF. New DWARF extensions
> >> DW_
rings are recorded in debug information for
>> post-compilation uses, and despite the name they are meant to be
>> recorded in DWARF as well as BTF. New DWARF extensions
>> DW_TAG_GNU_annotation and DW_AT_GNU_annotation are used to represent
>> these user annotations in DWARF.
>
es, and despite the name they are meant to be
> recorded in DWARF as well as BTF. New DWARF extensions
> DW_TAG_GNU_annotation and DW_AT_GNU_annotation are used to represent
> these user annotations in DWARF.
>
> This patch introduces the new DWARF extension DIE and attribute, and
&g
y have multiple occurrences of these attributes.
- The conveyance of that information in the DWARF output in the form of a new
DIE: DW_TAG_GNU_annotation, and a new attribute: DW_AT_GNU_annotation.
- The conveyance of that information in the BTF output in the form of two new
kinds of BTF
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF
Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu. Committed
to trunk.
Dave
---
testsuite: Add -gno-strict-dwarf option to dwarf2 inline[26].c tests
Some targets default to strict dwarf.
2025-03-17 John David Anglin
gcc/testsuite/ChangeLog:
PR testsuite/119220
Ping.
Patches 3-5 in the series have been reviewed, but depend heavily upon
the DWARF implementation in this patch.
It would be useful to have some indication of whether the new DWARF
implementation is generally OK...
Richard, your feedback on earlier iterations was very helpful, maybe
you
From: Ed Catmur
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Per https://wiki.dwarfstd.org/C++0x_Variadic_templates.md
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_param
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF
k we should never emit DW_AT_language_version without
DW_AT_language_name, but the other way around is possible, although
only at DWARF 6 time for languages which don't care about version.
For DWARF 5 we wouldn't bother with DW_AT_language_name in that case
and just emit DW_AT_language.
> The
Hi Jakub,
On Tue, 2025-01-07 at 20:22 +0100, Jakub Jelinek wrote:
> DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
> which is basically just a guarantee that the DWARF 6 draft
> DW_AT_language_{name,version} attribute codes and content of
> https://dwarfstd.o
that it required changing all the
> > > DWARF consumers to be able to debug C17 or later or C++17 or later
> > > sources.
> >
> > Do you plan to salvage the non-obsoleted parts of the above change?
>
> No. The switches on DW_AT_language value ar
May be add a feature request PR for this for Ada and Fortran to prevent us
from forgetting to evaluate the necessity or ability to provide that
flag/information?
Sorry for me using a wrong term or expression above. I have not yet any
knowledge or gotten in touch with DWARF stuff.
- Andre
On Wed
On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > So, this patch is an alternative to the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > patch, which had the major problem that it required changing all the
> > DWARF consumers to
> So, this patch is an alternative to the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> patch, which had the major problem that it required changing all the
> DWARF consumers to be able to debug C17 or later or C++17 or later
> sources.
Do you plan to
On Tue, 7 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
> which is basically just a guarantee that the DWARF 6 draft
> DW_AT_language_{name,version} attribute codes and content of
> https://dwarfstd.org/langua
Hi!
DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
which is basically just a guarantee that the DWARF 6 draft
DW_AT_language_{name,version} attribute codes and content of
https://dwarfstd.org/languages-v6.html can be used as an extension
in DWARF 5 and won't be ch
On Wed, 2024-11-27 at 15:18:39 +, Richard Biener wrote:
> I'm not sure it will work this way together with the output_die hunk,
> instead
> assemblers likely expect all this to happen close to the actual label
> emission, so I suggest to only split out the visibiltiy/globalizing fancy
> and emi
On 11/27/24 2:59 PM, Richard Biener wrote:
Did you test with -fdebug-types-section? This code should be still needed
to generate the linkonce debug-type sections. Note it doesn't work (very well)
when combined with LTO.
I used the tests in testsuite and now I also tested it with
nontrivia
On 11/27/24 3:12 PM, Richard Biener wrote:
I wonder why you could not always do this for a subset of symbols,
namely those exported from the current TU and building a symbol
based on the symbols assembler name?
That is, I dislike relying on a new flag_lto_debuginfo_assume_unique_filepaths
fla
On Wed, Nov 6, 2024 at 3:36 PM Michal Jires wrote:
>
> Die symbols are used for external references.
> Typically during LTO, early debug emits 'die_symbol+offset' for each
> possibly referenced DIE in future. Partitions in LTRANS phase then
> use these references.
>
> Originally die symbols are ha
On Wed, Nov 6, 2024 at 3:36 PM Michal Jires wrote:
>
> During Incremental LTO, contents of LTO partitions diverge because of
> external DIE references (DW_AT_abstract_origin).
>
> External references are in form 'die_symbol+offset'.
> Originally there is only single die_symbol for each compilation
e, int
> output_if_empty,
>/* Leave the marks on the main CU, so we can check them in
> output_pubnames. */
>if (oldsym)
> -{
> - unmark_dies (die);
> - die->die_id.die_symbol = oldsym;
> -}
> +unmark_dies (die);
> }
>
> /* Whether to generate the DWARF accelerator tables in .debug_pubnames
> --
> 2.47.0
>
On Thu, 21 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> DWARF now maintains DW_LANG_* code assignment online and 27 language codes
> have been assigned already after DWARF 5 has been released, see
> https://dwarfstd.org/languages.html
> including one added yesterday (DW_LANG_C23).
h at all and ignore all the
> post-DWARF 5 codes.
> Or shall we wait until gdb, elfutils, whatever else actually looks at
> DW_AT_language values is changed to handle the new codes and apply this
> patch after that (still one would need a new version of gdb/elfutils/etc.)?
> Or wait
Hi!
DWARF now maintains DW_LANG_* code assignment online and 27 language codes
have been assigned already after DWARF 5 has been released, see
https://dwarfstd.org/languages.html
including one added yesterday (DW_LANG_C23).
DWARF 6 plans to use something different, DW_AT_language_{name,version
On Thu, 21 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> DWARF changed the language code assignment to be on a web page and
> after DWARF 5 has been published already 27 codes have been assigned.
> We have some of those already in the header, but most of them were missing,
> includ
Hi!
DWARF changed the language code assignment to be on a web page and
after DWARF 5 has been published already 27 codes have been assigned.
We have some of those already in the header, but most of them were missing,
including one added just yesterday (DW_LANG_C23).
Note, this is really post
+unmark_dies (die);
}
/* Whether to generate the DWARF accelerator tables in .debug_pubnames
--
2.47.0
These patches allow adding additional die symbols, so that
external references represented as 'die_symbol+offset' don't diverge
contents of LTO partitions.
Bootstrapped/regtested on x86_64-linux
During Incremental LTO, contents of LTO partitions diverge because of
external DIE references (DW_AT_abstract_origin).
External references are in form 'die_symbol+offset'.
Originally there is only single die_symbol for each compilation unit and
its offsets are in 100'000s, which easily diverge.
D
Die symbols are used for external references.
Typically during LTO, early debug emits 'die_symbol+offset' for each
possibly referenced DIE in future. Partitions in LTRANS phase then
use these references.
Originally die symbols are handled only in root comp_unit and
in attributes.
This patch allow
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF
This patch by Pavel Safonov recognizes the new DWARF section names
used on macos Sequoia. Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
* macho.c (dwarf_section_names): Add __debug_addr and
__debug_line_str.
d97243588c8b5cbe8b657fd51f08038c42c81908
From: Tom Tromey
This changes the Ada compiler to emit DWARF information for Ada 'with'
and 'use' clauses. In particular, code like:
with Pck; use Pck;
will be emitted as:
<1><146a>: Abbrev Number: 23 (DW_TAG_module)
<146b> DW_AT_name
Pushed.
Gerald
gcc:
PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Focus on DWARF
only.
---
gcc/doc/install.texi | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 09559
tore signing key and signing method in DWARF _Unwind_FrameState
>
> _Unwind_FrameState already contains several CIE and FDE information (see the
> attributes below the comment "The information we care about from the CIE/FDE"
> in libgcc/unwind-dw2.h).
> The patch aims at
This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
architecture-specific structure containing CIE and FDE data related
to DWARF architecture extensions.
Hiding the architecture-specific attributes behind a handler has the
following benefits:
1. isolating those data from the
E" in libgcc/unwind-dw2.h).
The patch aims at moving the information from DWARF CIE (signing
key stored in the augmentation string) and FDE (the used signing
method) into _Unwind_FrameState along the already-stored CIE and
FDE information.
Note: those information have to be saved in frame_stat
This patch series is only a refactoring of the existing implementation of PAuth
and returned-address signing. The existing behavior is preserved.
1. aarch64: store signing key and signing method in DWARF _Unwind_FrameState
_Unwind_FrameState already contains several CIE and FDE information (see
On 2024-08-06 11:21, Richard Sandiford wrote:
Matthieu Longo writes:
This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
architecture-specific structure containing CIE and FDE data related
to DWARF architecture extensions.
Hiding the architecture-specific attributes behind a
information
(see the attributes below the comment "The information we care
about from the CIE/FDE" in libgcc/unwind-dw2.h).
The patch aims at moving the information from DWARF CIE (signing
key stored in the augmentation string) and FDE (the used signing
method) into _Unwind_FrameState
Matthieu Longo writes:
> This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
> architecture-specific structure containing CIE and FDE data related
> to DWARF architecture extensions.
>
> Hiding the architecture-specific attributes behind a handler has the
> follo
e attributes below the comment "The information we care
> about from the CIE/FDE" in libgcc/unwind-dw2.h).
> The patch aims at moving the information from DWARF CIE (signing
> key stored in the augmentation string) and FDE (the used signing
> method) into _Unwind_FrameStat
On 2024-07-19 15:54, Matthieu Longo wrote:
This patch series is only a refactoring of the existing implementation of PAuth
and returned-address signing. The existing behavior is preserved.
1. aarch64: store signing key and signing method in DWARF _Unwind_FrameState
_Unwind_FrameState already
t;The information we care
about from the CIE/FDE" in libgcc/unwind-dw2.h).
The patch aims at moving the information from DWARF CIE (signing
key stored in the augmentation string) and FDE (the used signing
method) into _Unwind_FrameState along the already-stored CIE and
FDE information.
N
This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
architecture-specific structure containing CIE and FDE data related
to DWARF architecture extensions.
Hiding the architecture-specific attributes behind a handler has the
following benefits:
1. isolating those data from the
E" in libgcc/unwind-dw2.h).
The patch aims at moving the information from DWARF CIE (signing
key stored in the augmentation string) and FDE (the used signing
method) into _Unwind_FrameState along the already-stored CIE and
FDE information.
Note: those information have to be saved in frame_stat
This patch series is only a refactoring of the existing implementation of PAuth
and returned-address signing. The existing behavior is preserved.
1. aarch64: store signing key and signing method in DWARF _Unwind_FrameState
_Unwind_FrameState already contains several CIE and FDE information (see
uite/gcc.dg/debug/btf/btf-5.c
>
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index 1b1b46455af6..7e9f2d91172b 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> @@ -3506,21 +3506,11 @@ set_debug_level (uint32_t dinfo, int extended, const
> char *arg,
> }
>else
&
{
- /* Make and retain the choice if both CTF and DWARF debug info are to
-be generated. */
- if (((dinfo == DWARF2_DEBUG) || (dinfo == CTF_DEBUG))
- && ((opts->x_write_symbols == (DWARF2_DEBUG|CTF_DEBUG))
- || (opts->x_write_symbols =
f80d5d4ba8f9..d58bea096a5f 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -3505,21 +3505,15 @@ set_debug_level (uint32_t dinfo, int extended, const
char *arg,
}
else
{
- /* Make and retain the choice if both CTF and DWARF debug info are to
-be generated. */
- if
eturn (UNSIGNED_8) p0 + 252 <= 3 ? 32 : 0;
> }
>
> The UNSIGNED_8-based trick eliminates one branch but relies on the wrap-around
> arithmetics of UNSIGNED_8. This size function is then translated into a DWARF
> procedure, but the wrap-around arithmetics is dropped, leading to
but relies on the wrap-around
arithmetics of UNSIGNED_8. This size function is then translated into a DWARF
procedure, but the wrap-around arithmetics is dropped, leading to a wrong size
calculation when the DWARF procedure is executed.
The fix also contains an optimization of unsigned compari
(uint32_t dinfo, int extended, const
char *arg,
}
else
{
- /* Make and retain the choice if both CTF and DWARF debug info are to
-be generated. */
- if (((dinfo == DWARF2_DEBUG) || (dinfo == CTF_DEBUG))
+ /* Any combination of DWARF, CTF and BTF is allowed together
On Tue, May 14, 2024 at 01:35:30PM +0200, Tom de Vries wrote:
> Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and
> -g3:
> ...
> $ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
> ...
>
> In section .debug_macro.dwo, we have:
&
Consider a hello world, compiled with -gsplit-dwarf and dwarf version 4, and
-g3:
...
$ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
...
In section .debug_macro.dwo, we have:
...
.Ldebug_macro0:
.value 0x4 # DWARF macro version number
.byte 0x2
gcc/testsuite/ChangeLog:
PR jit/110466
* jit.dg/jit.exp (jit-check-debug-info): Gracefully handle too
early versions of gdb that don't support our dwarf version, via
"unsupported".
(cherry picked from commit r14-2223-gc3c0ba5436170e)
Signed-off-by
dinfo, int extended, const
char *arg,
}
else
{
- /* Make and retain the choice if both CTF and DWARF debug info are to
-be generated. */
- if (((dinfo == DWARF2_DEBUG) || (dinfo == CTF_DEBUG))
+ /* Any combination of DWARF, CTF and BTF is allowed together
dinfo, int extended, const
char *arg,
}
else
{
- /* Make and retain the choice if both CTF and DWARF debug info are to
-be generated. */
- if (((dinfo == DWARF2_DEBUG) || (dinfo == CTF_DEBUG))
+ /* Any combination of DWARF, CTF and BTF is allowed together
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Add -gno-strict-dwarf to dg-options in various btf enum tests
The -gno-strict-dwarf option is needed to ensure enum signedness
is added to type_die.
2024-01-22 John David Anglin
gcc/testsuite/ChangeLog:
PR debug/113382
On Tue, Sep 19, 2023 at 11:02 PM Omar Sandoval wrote:
>
> On Tue, Sep 19, 2023 at 02:56:36PM +0200, Richard Biener wrote:
> > On Thu, Sep 14, 2023 at 8:42 AM Omar Sandoval wrote:
> > >
> > > Split DWARF files aren't processed by the linker, so DW_MACRO_import
On Tue, Sep 19, 2023 at 02:56:36PM +0200, Richard Biener wrote:
> On Thu, Sep 14, 2023 at 8:42 AM Omar Sandoval wrote:
> >
> > Split DWARF files aren't processed by the linker, so DW_MACRO_import
> > offsets aren't relocated and the .debug_macro.dwo sections are
On Thu, Sep 14, 2023 at 8:42 AM Omar Sandoval wrote:
>
> Split DWARF files aren't processed by the linker, so DW_MACRO_import
> offsets aren't relocated and the .debug_macro.dwo sections aren't
> deduplicated and merged. There's no clear way for this to work for
&
Tested on i686, x86_64 and aarch64 Darwin, also on x86_64 and aarch64
Linux. Having said this, some fallout might well be expected on Darwin
since the consumers have not had much use with GCC output where the
DWARF version is > 2, we will have to tackle that as it arises.
pushed to trunk, tha
Split DWARF files aren't processed by the linker, so DW_MACRO_import
offsets aren't relocated and the .debug_macro.dwo sections aren't
deduplicated and merged. There's no clear way for this to work for
split DWARF, so disable it.
gcc/ChangeLog:
PR debug/111409
From: Tom Tromey
An array whose index type is a nonstandard enum will be marked as
"packed", but should not emit DW_AT_bit_stride unless it is also
bit-packed.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_entity): Set bit-packed for
constrained and unconstrained array types.
Expose get_die_parent () so it can be used outside of dwarf2out.cc
gcc/
* dwarf2out.cc (get_die_parent): Make non-static.
* dwarf2out.h (get_die_parent): Add extern declaration here.
---
gcc/dwarf2out.cc | 2 +-
gcc/dwarf2out.h | 1 +
2 files changed, 2 insertions(+), 1 deletion
The "btf_decl_tag" attribute is handled by constructing a
DW_TAG_GNU_annotation DIE for each occurrence to record the argument
string in debug information. The DIEs are children of the declarations
they annotate, with the following format:
DW_TAG_GNU_annotation
DW_AT_name "btf_decl_tag"
versions of gdb that don't support our dwarf version, via
"unsupported".
---
gcc/testsuite/jit.dg/jit.exp | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 3568dbb9d63..8bf7e51c24f 100644
--- a/gcc/t
l, and plain -gno-dwarf will enable (dwarf!) debug output.
>
> Rejecting the negative forms avoids interpreting sensible behavior
> to combinations of options like -gdwarf-5 -gno-dwarf-3 and sticks to
> the behavior that later -g options simply override earlier ones and
> th
The following adds RejectNegative to the gdwarf, gdwarf-, ggdb and gvms
options since the current behavior is to treat the negative variant
the same as the positive variant. In particular -ggdb -gno-gdb
do not cancel, and plain -gno-dwarf will enable (dwarf!) debug output.
Rejecting the negative
On 18/01/2023 17:18, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives
acco
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives
accordingly.
This patch also adds support to emit ".pacspval&quo
On 13/01/2023 17:44, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives
acco
On Fri, Jan 13, 2023 at 10:39:59PM +, Richard Earnshaw wrote:
> > > It is. The new unwinder fortunately doesn't suffer from this (at least I
> > > think it doesn't), but in older gccs the unwinder could be split
> > > across different
> > > objects, having e.g. parts of the unwinder in one sha
On 13/01/2023 22:25, Richard Earnshaw (lists) via Gcc-patches wrote:
On 13/01/2023 22:12, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> I'm afraid increasing number of DWARF registers is ABI incompatible
change.
>
On 13/01/2023 22:12, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> I'm afraid increasing number of DWARF registers is ABI incompatible change.
> E.g. libgcc __frame_state_for function fills in:
> typedef struct frame_state
>
On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> > I'm afraid increasing number of DWARF registers is ABI incompatible change.
> > E.g. libgcc __frame_state_for function fills in:
> > typedef struct frame_state
> > {
> >void *cf
On 13/01/2023 21:58, Richard Earnshaw (lists) via Gcc-patches wrote:
On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via
Gcc-patches wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches
wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", &quo
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches
wrote:
> Hello,
>
> This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
> hard-register and also
> updates the ".save", ".cfi_register", ".cfi_offset&qu
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives
accordingly.
This patch also adds support to emit ".pacspval&quo
Richard Sandiford writes:
> Jakub Jelinek writes:
>> On Thu, Jan 12, 2023 at 04:50:07PM +, Richard Sandiford wrote:
>>> I'm jumping in here without fully understanding the context, so maybe this
>>> is exactly your point, but: the SIMD/FP DWARF registe
Jakub Jelinek writes:
> On Thu, Jan 12, 2023 at 04:50:07PM +, Richard Sandiford wrote:
>> I'm jumping in here without fully understanding the context, so maybe this
>> is exactly your point, but: the SIMD/FP DWARF registers are supposed to be
>> size 8 regardless of
On Thu, Jan 12, 2023 at 04:50:07PM +, Richard Sandiford wrote:
> I'm jumping in here without fully understanding the context, so maybe this
> is exactly your point, but: the SIMD/FP DWARF registers are supposed to be
> size 8 regardless of which features are enabled. That'
ctly even without
> any changes - as noted in the PRs, if libgcc is built without SVE, it will
> hardcode 8, while if it is built with SVE, it will be runtime dependent and
> will be wrong in theory when some HW has 2048 bit SVE vectors - when it is
> 256 bytes), but still watching into wh
On Tue, Jan 03, 2023 at 02:25:21PM +0100, Florian Weimer wrote:
> > Though, I still wonder, because all of this is a hack for a single target
> > - x86_64-linux -m64 - I think no other target has similar constant
> > sizes,
>
> Really? That's odd.
I've tried about 30 cross compilers I had around
>> -extern int dwarf_reg_sizes_constant ();
>> +/* Query size information about DWARF registers. */
>> +struct dwarf_single_register_size
>> +{
>> + dwarf_single_register_size();
>
> Formatting, space before (
>
>> @@ -334,27 +333,39 @@ generate_dw
* Query size information about DWARF registers. */
> +struct dwarf_single_register_size
> +{
> + dwarf_single_register_size();
Formatting, space before (
> @@ -334,27 +333,39 @@ generate_dwarf_reg_sizes (poly_uint16 *sizes)
> targetm.init_dwarf_reg_sizes_extra (sizes);
>
dwarf_single_register_size for obtaining DWARF register sizes.
Define __LIBGCC_DWARF_REG_MAXIMUM__.
libgcc/
* unwind-dw2.c (dwarf_reg_size): Use
__LIBGCC_DWARF_REG_MAXIMUM__.
---
gcc/c-family/c-cppbuiltin.cc | 12
gcc/debug.h | 13 -
gcc/doc
* Jeff Law:
> On 11/8/22 11:05, Florian Weimer via Gcc-patches wrote:
>> The sizes are compile-time constants. Create a vector with them,
>> so that they can be inspected at compile time.
>>
>> * gcc/dwarf2cfi.cc (init_return_column_size): Remove.
>> (init_one_dwarf_reg_size): Adjust.
>
On 09/11/2022 14:32, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives
acco
Ping!!
From: Gcc-patches
on behalf of
Srinath Parvathaneni via Gcc-patches
Sent: 09 November 2022 14:32
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Kyrylo Tkachov
Subject: [GCC][PATCH 13/15, v4] arm: Add support for dwarf debug directives and
pseudo
Hi,
This patch was applied to mainline back in August, but was held back
from backporting until after 12.2 release to allow some more time for
testing. There are no further regressions been found, so have
backported to the releases/gcc-12 branch.
Bootstrapped and regression tested on x86_64-linu
1 - 100 of 1048 matches
Mail list logo
