On Wed, Sep 1, 2021 at 7:25 PM Indu Bhagat wrote:
>
> On 8/24/21 12:55 AM, Richard Biener wrote:
> > On Mon, Aug 23, 2021 at 11:18 PM Indu Bhagat via Gcc-patches
> > wrote:
> >>
> >> Hello,
> >>
> >> What is the expected DWARF for extern variable in the following cases? I
> >> am seeing that the
On 8/24/21 12:55 AM, Richard Biener wrote:
On Mon, Aug 23, 2021 at 11:18 PM Indu Bhagat via Gcc-patches
wrote:
Hello,
What is the expected DWARF for extern variable in the following cases? I
am seeing that the DWARF generated is different with gcc8.4.1 vs gcc-trunk.
Testcase 2
--
ex
On Mon, Aug 23, 2021 at 11:18 PM Indu Bhagat via Gcc-patches
wrote:
>
> Hello,
>
> What is the expected DWARF for extern variable in the following cases? I
> am seeing that the DWARF generated is different with gcc8.4.1 vs gcc-trunk.
>
> Testcase 1
> --
> extern const char a[];
>
> int foo
On Fri, May 28, 2021 at 8:56 PM Eric Botcazou wrote:
>
> But only for the reference variant (dw_val_class_die_ref). This is needed for
> variable-sized types declared at library level in Ada.
>
> Tested on x86-64/Linux, both GCC and GDB, OK for the mainline?
OK.
Richard.
>
> 2021-05-28 Eric B
> Yes, but even bitsizetype is undistinguishable from other (usually 2 *
> pointer size) precision integral types.
OK, I can propose the attached patch. The typed_binop_from_tree computation
works on my Ada testcase in 32-bit mode from within GDB, but not in 64-bit
mode because GDB chokes with:
On Tue, Apr 27, 2021 at 12:18:44AM +0200, Eric Botcazou wrote:
> > At least sizetype is for GIMPLE compatible with size_t or unsigned long (or
> > whatever unsigned type has the same precision), so this looks wrong to me.
>
> It's for bitsizetype here, as it's a conversion from bits into bytes, so
> At least sizetype is for GIMPLE compatible with size_t or unsigned long (or
> whatever unsigned type has the same precision), so this looks wrong to me.
It's for bitsizetype here, as it's a conversion from bits into bytes, so
larger than DWARF2_ADDR_SIZE.
> For non-strict DWARF or DWARF5 and a
On Mon, Apr 26, 2021 at 06:49:22PM +0200, Eric Botcazou wrote:
> the compiler can synthesize DWARF functions to describe the location and size
> of components in discriminated record types with variant part in Ada, but in
> peculiar cases the compiler drops expressions on the floor, for example in
On Fri, May 10, 2019 at 2:40 PM Nathan Sidwell wrote:
>
> When poking at some dwarf bugs, which were ultimately fixed by Richard,
> I made a couple of cleanups. The first two are pretty obvious comment
> clarification, but the last fragment is a more invasive control flow
> change. In that case
Hi,
On Sat, 1 Sep 2018, Segher Boessenkool wrote:
> > With -fno-omit-frame-pointer, arg pointer is eliminated with hard frame
> > pointer. But
> >
> > commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
> > Author: hjl
> > Date: Thu Aug 10 15:29:05 2017 +
> >
> > i386: Don't use frame p
Hi!
On Fri, Aug 31, 2018 at 02:54:17PM -0700, H.J. Lu wrote:
> On Fri, Aug 31, 2018 at 1:32 PM, Jason Merrill wrote:
> > On Fri, Aug 31, 2018 at 3:33 PM, H.J. Lu wrote:
> >> On Thu, Aug 30, 2018 at 10:21 AM, Jason Merrill wrote:
> >>>
> r138335 allowed arg_pointer_rtx to be eliminated by e
On Fri, Aug 31, 2018 at 1:32 PM, Jason Merrill wrote:
> On Fri, Aug 31, 2018 at 3:33 PM, H.J. Lu wrote:
>> On Thu, Aug 30, 2018 at 10:21 AM, Jason Merrill wrote:
>>>
r138335 allowed arg_pointer_rtx to be eliminated by either FP or SP,
but only when dynamic stack alignment is supported.
On Fri, Aug 31, 2018 at 3:33 PM, H.J. Lu wrote:
> On Thu, Aug 30, 2018 at 10:21 AM, Jason Merrill wrote:
>>
>>> r138335 allowed arg_pointer_rtx to be eliminated by either FP or SP,
>>> but only when dynamic stack alignment is supported. In this case,
>>> arg_pointer_rtx is eliminated by FP even
On Wed, Nov 22, 2017 at 02:40:39AM -0200, Alexandre Oliva wrote:
> On Nov 21, 2017, Jakub Jelinek wrote:
>
> > On Wed, Nov 15, 2017 at 05:05:36AM -0200, Alexandre Oliva wrote:
>
> >> This patch introduces a new DWARF attribute to indicate that a function
> >> is a partial copy of its abstract or
On Nov 21, 2017, Jakub Jelinek wrote:
> On Wed, Nov 15, 2017 at 05:05:36AM -0200, Alexandre Oliva wrote:
>> This patch introduces a new DWARF attribute to indicate that a function
>> is a partial copy of its abstract origin, specifically, that its entry
>> point does not correspond to the entry
On Wed, Nov 15, 2017 at 05:05:36AM -0200, Alexandre Oliva wrote:
> debug info: partial noentry functions: infra
>
> This is the first patch of a set that addresses two different but
> somewhat related issues.
>
> On the one hand, after partial inlining, the non-inlined function
> fragment is outp
On 11/15/2017 12:05 AM, Alexandre Oliva wrote:
> debug info: partial noentry functions: infra
>
> This is the first patch of a set that addresses two different but
> somewhat related issues.
>
> On the one hand, after partial inlining, the non-inlined function
> fragment is output in a way that d
> On Jun 2, 2017, at 16:43 , Olivier Hainque wrote:
>
> VxWorks has had support for dwarf unwinding for many years now. This patch
> adjusts our configuration accordingly.
A few extra details:
I noticed this while trying to build an Ada runtime for VxWorks from the
current mainline.
A few sou
On Wed, 15 Feb 2017, Michael Eager wrote:
> The DWARF Debugging Information Format Standards Committee is pleased
> to announce the availability of Version 5 of the DWARF Debugging Format
> Standard.
This patch, which I just applied, updates the GCC 7 release notes
accordingly.
(Now it's only
Ping!
Regards
Senthil
On Fri, Apr 10, 2015 at 12:19:36PM +0530, Senthil Kumar Selvaraj wrote:
> Hi,
>
> This (rather big) patch is an attempt to generate per function DWARF
> information for functions that go into their own sections (through
> -ffunction-section or otherwise). This is so th
On Mon, Dec 2, 2013 at 1:59 PM, Cary Coutant wrote:
> This is OK, but your patch also has a local change to contrib/mklog.
> Please be careful not to commit that.
Committed without the contrib/mklog portion.
Also committing on google/gcc-4_8 and google/main.
> gcc/ChangeLog
>
> 2013-12-02 Sterling Augustine
>
> * dwarf2out.c (output_pubnames): Use comp_unit_die ()->die_offset
> when there
> isn't a skeleton die.
This is OK, but your patch also has a local change to contrib/mklog.
Please be careful not to commit that.
Thanks!
-cary
On Tue, Oct 22, 2013 at 12:05 PM, Sterling Augustine
wrote:
> On Thu, Oct 17, 2013 at 12:09 PM, Sterling Augustine
> wrote:
>> The enclosed patch (which depends on
>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01395.html), ports the
>> new -ggnu-pubnames option from google 4.8 to trunk.
>>
>> -
On Thu, Oct 17, 2013 at 12:09 PM, Sterling Augustine
wrote:
> The enclosed patch (which depends on
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01395.html), ports the
> new -ggnu-pubnames option from google 4.8 to trunk.
>
> -gnu-pubnames enable the gold linker to to generate a better
> .gdb_ind
> gcc/ChangeLog
> 013-07-25 Sterling Augustine
>
> * dwarf2out.c (size_of_pubnames): Move code to...
> (include_pubname_in_output): ...here. New.
> (want_pubnames): Rearrange.
> (output_pubnames): Call include_pubname_in_output. Move assertion.
This is OK. Thanks!
-cary
Hello,
May I have a review from the DWARF, the ARM and RS6000 maintainers for
comments/approval ?
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01613.html
Needed to fix the powerpc-spe bootstrap referenced in bugzilla #57389
Many Thanks
Christian
Christian Bruel wrote:
>> However I feel a li
Christian Bruel wrote:
> However I feel a little bit uncomfortable with this solution that
> doesn't seem to fix the root cause. The dbx_register_number hooks is
> called basically from two places : dwarf2cfi.c and dwarf2out.c. That
> show different uses: either we want to refer to the hard regno
On 05/16/2013 12:27 AM, Cary Coutant wrote:
>>> How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The
>>> bare use of DBX_REGISTER_NUMBER earlier in that function is protected
>>> by a gcc_assert, but this one isn't.
>>
For the respective targets maintainers that drop into the thread:
Yes, this looks good. OK for trunk, but please add a note about those
additional changes you made to the ChangeLog entry. Thanks!
Thanks, done with this entry:
2013-05-21 Christian Bruel
* dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for
spanning register
> > How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The
> > bare use of DBX_REGISTER_NUMBER earlier in that function is protected
> > by a gcc_assert, but this one isn't.
>
> OK dbx_reg_number better than DBX_REGISTER_NUMBER here.
> while we are on it, it looks like the spanning ca
Hello,
On 04/30/2013 09:05 PM, Cary Coutant wrote
>
> How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The
> bare use of DBX_REGISTER_NUMBER earlier in that function is protected
> by a gcc_assert, but this one isn't.
OK dbx_reg_number better than DBX_REGISTER_NUMBER here.
while w
2013-04-26 Christian Bruel
* dwarf2out.c (multiple_reg_loc_descriptor): Use DBX_REGISTER_NUMBER
for spaning registers.
s/spaning/spanning/
Index: dwarf2out.c
===
--- dwarf2out.c (revision 198287)
+++ dwarf2out.c
> 2013-04-22 Sterling Augustine
>
> * dwarf2out.c (skeleton_debug_str_hash, comp_dir_string,
> add_skeleton_AT_string. comp_dir_string, debug_str_dwo_section): New.
s/./,/
I think comp_dir_string only needs to be mentioned once.
> (DEBUG_STR_DWO_SECTION): Rename to ...
On Tue, Nov 6, 2012 at 5:02 PM, Dominique Dhumieres wrote:
>> I'm testing the enclosed patch on my end. Does it happen to work for you?
>
> I am now past the previous error. Full answer tomorrow morning.
>
> Thanks
>
> Dominique
I have committed the above fix as obvious. If there is additional
br
> I'm testing the enclosed patch on my end. Does it happen to work for you?
I am now past the previous error. Full answer tomorrow morning.
Thanks
Dominique
On Tue, Nov 6, 2012 at 4:29 PM, Dominique Dhumieres wrote:
>> Committed as attached. Thanks everyone.
>
> This (r193267) breaks bootstrap on x86_64-apple-darwin10:
>
> ...
> g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -W -Wall -Wno-narrowing -Wwrite-strings -Wc
> Committed as attached. Thanks everyone.
This (r193267) breaks bootstrap on x86_64-apple-darwin10:
...
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-vari
On Mon, Nov 5, 2012 at 3:18 PM, Cary Coutant wrote:
>> +/* %:replace-extension spec function. Replaces the extension of the
>> + first argument with the second argument. */
>> +
>> +const char *
>> +replace_extension_spec_func (int argc, const char **argv)
>> +{
>> + char *name;
>> + char *p
> +/* %:replace-extension spec function. Replaces the extension of the
> + first argument with the second argument. */
> +
> +const char *
> +replace_extension_spec_func (int argc, const char **argv)
> +{
> + char *name;
> + char *p;
> + char *result;
> +
> + if (argc != 2)
> +fatal_err
Hi Jason,
Just wanted to be sure you saw this. I'm hoping to get it in for stage 1.
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02684.html
Sterling
On 10/10/2012 08:41 PM, Cary Coutant wrote:
I'm working on a follow-up patch to eliminate the duplicate references
to ".LVL" symbols by keeping a direct-lookup table in
dwarf2out_var_location. That will eliminate 310,266 of the 312,061
duplicates (99.4%) without using a hash table. With that patc
>>> The potential savings here didn't seem worth the effort of adding a
>>> pass over another table to assign slots in .debug_addr. In practice,
>>> we're seeing very few slots zeroed out here.
>
> And how many duplicate entries? What strategy does Cary's patch use to
> avoid those?
I picked a co
On 07/25/2012 07:54 PM, Sterling Augustine wrote:
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant wrote:
Perhaps instead of having a val_index field in each attribute you should
have the attribute point to something like an indirect_string_node for
addresses as well.
The potential savings here
+ if (dwarf_version >= 4 || dwarf_split_debug_info)
>>>
>>> Shouldn't -gsplit-debug require -gdwarf-4+ anyway?
>>
>> Seems better to check explicitly than to rely on an implied relationship.
>
> I think Jason is right here. Although they are theoretically separate,
> there has been no tes
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant wrote:
>>> +/* Remove an entry from the addr table. Since we have already numbered
>>> + all the entries, the best we can do here is null it out. */
>>
>> This sounds like a design flaw. Since we have everything in memory, there's
>> no reason we
>> +/* Remove an entry from the addr table. Since we have already numbered
>> + all the entries, the best we can do here is null it out. */
>
> This sounds like a design flaw. Since we have everything in memory, there's
> no reason we shouldn't be able to pack the table appropriately. Why can
On 07/18/2012 05:44 PM, Sterling Augustine wrote:
+/* Remove an entry from the addr table. Since we have already numbered
+ all the entries, the best we can do here is null it out. */
This sounds like a design flaw. Since we have everything in memory,
there's no reason we shouldn't be abl
On 2012/07/20 00:37:15, Cary wrote:
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c
File gcc/dwarf2out.c (right):
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c#newcode8517
gcc/dwarf2out.c:8517:
Should use SKELETON_COMP_DIE_ABBREV here instead of 1.
http://
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c
File gcc/dwarf2out.c (right):
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c#newcode8517
gcc/dwarf2out.c:8517:
Should use SKELETON_COMP_DIE_ABBREV here instead of 1.
http://codereview.appspot.com/6305113/diff/3001/
On 2012/06/01 17:58:41, saugustine wrote:
The enclosed patch updates the earlier patch to address all of the
feedback I
have gotten regarding generating pubnames. It fixes the offset problem
in
the pubtypes table; switches DW_AT_pubtypes to a flag and so on.
It also adds and documents a ne
On 05/30/2012 01:52 PM, Cary Coutant wrote:
At the time we emit the pubtypes table, we have a pointer to the DIE
I can add a field to the comdat_type_node structure to keep track of
the skeleton DIE for a given type unit, so that I can easily get the
right DIE offset for cases where there is a s
> At the time we emit the pubtypes table, we have a pointer to the DIE
> that has been moved to the type unit, and there's no mapping from that
> back to the skeleton DIE. As it stands, we don't even emit a skeleton
> DIE unless one of its descendants is a declaration, so we can't count
> on always
>>> Yes, I understand that's broken, but there are no consumers at this
>>> point that make any use of that offset. Would it be acceptable if we
>>> just put 0 there? (Given that I expect .debug_pub* to go away soon, I
>>> don't think it's worth the trouble of filling in the offset with
>>> anythin
On Tue, May 22, 2012 at 01:04:15PM -0700, Cary Coutant wrote:
> That might be workable. Let me take a look at the gold changes I'd
> need to make for that.
>
> They don't have to be relocations, though -- since they're only used
> by the linker, a raw section-relative offset would be sufficient.
> Yes, but I would expect this table lookup to be faster than going to the
> disk to read the CU DIE and abbrev in order to check for the attribute.
> OTOH, I suppose you need to read it anyway if you want to check somehow
> whether you should trust the pub* information.
Right. I also need to rea
On 05/22/2012 01:27 PM, Sterling Augustine wrote:
Anonymous namespaces are funky in general, but gdb would like to be
able to do things like tab completion on:
(gdb) b '(anonymous namespace)::
(gdb) b 'foo::(anonymous namespace)::
Without being able to lookup anonymous namespaces, gdb has no id
> I would expect the linker to start by processing the pubnames/pubtypes
> sections, and then if it wants to look through the CUs as well it already
> knows which ones it can skip.
>
> The presence or absence of an attribute seems like a fragile way to
> determine whether or not particular debug in
On Tue, May 22, 2012 at 10:19 AM, Jason Merrill wrote:
I'll let Cary handle the other questions.
> Yes, I agree that we want to put "some_function" in pubnames. I still don't
> see how putting the anonymous namespace itself in pubnames helps at all. As
> far as pubnames is concerned, the anony
On 05/21/2012 02:39 PM, Cary Coutant wrote:
The DW_AT_GNU_pubnames/pubtypes attributes serve two purposes: (1)
they let the linker know which CUs have pubnames & pubtypes sections,
and (2) they let us know that the pubnames and pubtypes are "reliable"
(relative to the incomplete sections that GCC
>> The entire motivation for this patch, including the proposed new
>> attributes is at:
>>
>> http://gcc.gnu.org/wiki/DebugFission
>>
>> In particular, the section titled, "Building a GDB Index".
>
> OK, I've read that section and I still don't understand why the consumer
> would need a pointer fr
On 05/18/2012 07:34 PM, saugust...@google.com wrote:
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at http://gcc.gnu.org/wiki/DebugFission.
Right. Not sure why I missed the pubtypes bits on that page before...
The code I removed doesn't
Hi Jasaon,
Thanks so much for reviewing this patch. I realize it is a lot to see.
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at http://gcc.gnu.org/wiki/DebugFission. I
have several more patches dealing with fission coming.
Fission has b
This patch makes a lot of changes to the behavior of .debug_pubnames
that I haven't seen any discussion of, and that don't seem obvious to
me. Can you point me at discussion threads?
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c
File gcc/dwarf2out.c (left):
http://codereview.app
On Thu, May 10, 2012 at 9:08 AM, Sterling Augustine
wrote:
> The enclosed patch fixes many issues with pubnames and pubtypes. It generates
> them for many more variables and with mostly correct and canonical dwarf
> names.
>
> This patch should not affect any target that does not use pubnames.
>
On 05/03/2012 04:17 PM, Cary Coutant wrote:
I believe I was just replicating the existing practice of putting
definitions at the top level, with a DW_AT_specification pointing to a
declaration DIE within the namespace/class hierarchy when necessary.
Yeah, I seem to remember there being a debugg
> Incidentally, I notice that we have unnecessary duplication in the type
> units. For instance, with nested-3.C:
>
> .uleb128 0x2 # (DIE (0x25) DW_TAG_namespace)
> .long .LASF0 # DW_AT_name: "thread"
> # DW_AT_declaration
> .long 0x34 # DW_AT
Thanks, committed.
(And sorry for the truncated subject).
Tristan.
On Mar 14, 2012, at 6:50 PM, Jason Merrill wrote:
> OK.
>
> Jason
OK.
Jason
On Wed, 2011-07-20 at 20:00 +0200, Jakub Jelinek wrote:
> On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
> > but wait until the DWARF committee has had an
> > opportunity to review the proposal and incorporate it into a future version
> > of DWARF. Should you discover a need for an
On 07/20/2011 11:00 AM, Jakub Jelinek wrote:
On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
It took me a few days to review the current DWARF macinfo specification
and review this proposal.
The existing macro data format is clearly in need of revision. I don't
think that there
On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
> It took me a few days to review the current DWARF macinfo specification
> and review this proposal.
>
> The existing macro data format is clearly in need of revision. I don't
> think that there is any way to modify this format whic
On 07/13/2011 11:20 AM, Jakub Jelinek wrote:
Hi!
The current .debug_macinfo format isn't very much extensible
and is not really designed to allow reducing of duplicate debug
info, so when compilers want to produce maco information, size
of .debug_macinfo is prohibitive.
We are discussing some e
72 matches
Mail list logo
