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
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.
(generate_dw
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
156..d45d20478b4 100644
--- a/gcc/dwarf2cfi.cc
+++ b/gcc/dwarf2cfi.cc
@@ -334,6 +334,29 @@ generate_dwarf_reg_sizes (poly_uint16 *sizes)
targetm.init_dwarf_reg_sizes_extra (sizes);
}
+/* Return 0 if the DWARF register sizes are not constant, otherwise
+ return the size constant. */
The parameters fs->data_align and fs->code_align always have fixed
values for a particular target in GCC-generated code. Specialize
execute_cfa_program for these values, to avoid multiplications.
gcc/
* c-family/c-cppbuiltin.c (c_cpp_builtins): Define
__LIBGCC_DWARF_CIE_DATA_ALIG
ter size
@end deftypefn
-@deftypefn {Target Hook} void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree
@var{address})
+@deftypefn {Target Hook} void TARGET_INIT_DWARF_REG_SIZES_EXTRA (poly_uint16
*@var{sizes})
If some registers are represented in Dwarf-2 unwind information in
multiple pieces, defin
> Am 07.09.2022 um 16:37 schrieb Martin Liška :
>
> On 9/7/22 15:43, David Edelsohn wrote:
>> On Wed, Sep 7, 2022 at 7:45 AM Martin Liška > <mailto:mli...@suse.cz>> wrote:
>>
>> Hi.
>>
>>The patch restores DWARF support fo
On 9/7/22 15:43, David Edelsohn wrote:
> On Wed, Sep 7, 2022 at 7:45 AM Martin Liška <mailto:mli...@suse.cz>> wrote:
>
> Hi.
>
> The patch restores DWARF support for AIX target where XCOFF file
> container is used.
> Verified before and after the pat
On Wed, Sep 7, 2022 at 7:45 AM Martin Liška wrote:
> Hi.
>
> The patch restores DWARF support for AIX target where XCOFF file container
> is used.
> Verified before and after the patch, gcc119 machine (AIX) could not build
> any run-time library,
> now it can.
>
> Read
Hi Iain,
> Excerpts from Rainer Orth's message of September 7, 2022 2:40 pm:
>> Hi Iain,
>>
Yes, this is data related. The DSO registry picks up nothing in the
miscompiled stage2 compiler, leaving all data uninitialized. The stage1
compiler works, and runs all module constructors
Excerpts from Rainer Orth's message of September 7, 2022 2:40 pm:
> Hi Iain,
>
>>> Yes, this is data related. The DSO registry picks up nothing in the
>>> miscompiled stage2 compiler, leaving all data uninitialized. The stage1
>>> compiler works, and runs all module constructors ahead of compilat
Hi Iain,
>> Yes, this is data related. The DSO registry picks up nothing in the
>> miscompiled stage2 compiler, leaving all data uninitialized. The stage1
>> compiler works, and runs all module constructors ahead of compilation.
>>
>
> Ohh, backtrack on that, analysis is correct, but it is a com
On Wed, Sep 7, 2022 at 1:45 PM Martin Liška wrote:
>
> Hi.
>
> The patch restores DWARF support for AIX target where XCOFF file container is
> used.
> Verified before and after the patch, gcc119 machine (AIX) could not build any
> run-time library,
> now it can.
>
&
Hi.
The patch restores DWARF support for AIX target where XCOFF file container is
used.
Verified before and after the patch, gcc119 machine (AIX) could not build any
run-time library,
now it can.
Ready to be installed?
Thanks,
Martin
PR bootstrap/106855
gcc/ChangeLog
Excerpts from Iain Buclaw's message of September 6, 2022 11:41 pm:
> Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
>> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>>> Hi Iain,
>>>
> there is indeed ;-) The previous d21 emits
>
> binary./26
Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>> Hi Iain,
>>
there is indeed ;-) The previous d21 emits
binary./266566/gcc/d21
version v2.100.1
predefs GNU D_Version2 Litt
Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
> Hi Iain,
>
>>> there is indeed ;-) The previous d21 emits
>>>
>>> binary./266566/gcc/d21
>>> version v2.100.1
>>>
>>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>>> GNU_StackGrowsDown GNU_InlineAsm assert D
Hi Iain,
>> there is indeed ;-) The previous d21 emits
>>
>> binary./266566/gcc/d21
>> version v2.100.1
>>
>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>> D_Invariants D_ModuleInfo D_Exceptions D_T
Excerpts from Rainer Orth's message of September 6, 2022 2:04 pm:
> Hi Iain,
>
>> Is there a difference in output from `./gcc/d21 -quiet -v` ?
>>
>> Pay attention to any predefs that have suddenly appeared or disappeared.
>
> there is indeed ;-) The previous d21 emits
>
> binary./266566/gcc
Hi Iain,
> Is there a difference in output from `./gcc/d21 -quiet -v` ?
>
> Pay attention to any predefs that have suddenly appeared or disappeared.
there is indeed ;-) The previous d21 emits
binary./266566/gcc/d21
version v2.100.1
predefs GNU D_Version2 LittleEndian GNU_DWARF2_Excepti
Excerpts from Rainer Orth's message of September 6, 2022 9:42 am:
> Hi Iain,
>
>> Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
>>> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>>>
>>> Ah yes - I think, even if a bit verbose, this is exactly how it was supposed
>>> t
Hi Iain,
> Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
>> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>>>
>>> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
>>> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>>> >
>>> >> Excerpts from J
Excerpts from Richard Biener's message of September 1, 2022 8:28 am:
> On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>>
>> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
>> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>> >
>> >> Excerpts from Joseph Myers's mess
On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>
> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> >
> >> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> >> > On Fri, 26 Aug 2022, Richard Biener
Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> >
>> >> I was hoping Joseph would ch
On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> >
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread
Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>
>> I was hoping Joseph would chime in here - I recollect debugging this kind
>> of thing and a thread about this a while back but unfortunately I do not
>> remember the
On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> I was hoping Joseph would chime in here - I recollect debugging this kind
> of thing and a thread about this a while back but unfortunately I do not
> remember the details here (IIRC some things get included where they
> better should no
On Tue, Aug 16, 2022 at 11:17 PM Iain Buclaw via Gcc-patches
wrote:
>
> Hi,
>
> Because targetdm contains hooks pertaining to both the target platform
> and cpu, it tries to pull in both platform and cpu headers via tm_d.h in
> the source file where TARGETDM_INITIALIZER is used.
>
> Since 12.0, th
On 19/08/2022 11:04, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
.save {ra_auth_code} and .cfi_offset ra_auth_code dwarf directives for
the PAC feature
in Armv8.1-M architecture
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
.save {ra_auth_code} and .cfi_offset ra_auth_code dwarf directives for
the PAC feature
in Armv8.1-M architecture.
RA_AUTH_CODE register number is 107 and it's dwarf register number i
Hi,
Because targetdm contains hooks pertaining to both the target platform
and cpu, it tries to pull in both platform and cpu headers via tm_d.h in
the source file where TARGETDM_INITIALIZER is used.
Since 12.0, this has caused problems when there is no platform (*-elf),
resulting in default-d.cc
Ping!!
> -Original Message-
> From: Gcc-patches bounces+srinath.parvathaneni=arm@gcc.gnu.org> On Behalf Of Srinath
> Parvathaneni via Gcc-patches
> Sent: 05 May 2022 12:02
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw
> Subject: [PATCH v2][GCC] ar
On Tue, Jun 7, 2022 at 11:44 PM David Faust via Gcc-patches
wrote:
OK
> gcc/
>
> * dwarf2out.cc (dw_get_die_parent): New function.
> * dwarf2out.h (dw_get_die_parent): Declare it here.
> ---
> gcc/dwarf2out.cc | 8
> gcc/dwarf2out.h | 1 +
> 2 files changed, 9 insertio
The "debug_annotate_decl" and "debug_annotate_type" attributes are
handled by constructing DW_TAG_GNU_annotation DIEs. These DIEs are
children of the declarations or types which they annotate, and convey
the information via a string constant.
gcc/
* dwarf2out.cc (gen_decl_annotation_dies)
gcc/
* dwarf2out.cc (dw_get_die_parent): New function.
* dwarf2out.h (dw_get_die_parent): Declare it here.
---
gcc/dwarf2out.cc | 8
gcc/dwarf2out.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 29f32ec6939..9c61026bb34 1
Szabolcs Nagy writes:
> The 05/13/2022 16:35, Richard Sandiford wrote:
>> Szabolcs Nagy via Gcc-patches writes:
>> > The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
>> > DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
> >> a compile-and-link test rather than a compile-only test.
>
> OK, thanks.
Thank you Richard. Pushed to master.
--
Joel
The 05/13/2022 16:35, Richard Sandiford wrote:
> Szabolcs Nagy via Gcc-patches writes:
> > The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
> > DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
> > toggles the return address signedne
S 6, we have about 150 tests failing due to a link failure.
>> When investigating, we found that all the tests were failing
>> due to the use of -gsplit-dwarf.
>>
>> On this platform, using -gsplit-dwarf currently causes an error
>> during the link:
>>
>>
Currently, a 64-bit gnatsymbolize fails to output line numbers and
accurate symbol names when run on 32-bit executables (and vice-versa).
This is because a couple of spots in System.Dwarf_Lines expect the
Address_Size found in the DWARF data to match the host Address'Size.
This patch cor
found that all the tests were failing
> due to the use of -gsplit-dwarf.
>
> On this platform, using -gsplit-dwarf currently causes an error
> during the link:
>
> | /[...]/ld: a.out section `.unexpected_sections' will not fit
> |in region `UNEXP
1 - 100 of 1007 matches
Mail list logo
