Re: DWARF for extern variable

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

Re: DWARF for extern variable

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 --

Re: DWARF for extern variable

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

Re: [DWARF] Also generate DW_OP_GNU_variable_value at file scope

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

Re: [DWARF] Fix signedness issue in DWARF functions (2)

> 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

Re: [DWARF] Fix signedness issue in DWARF functions (2)

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,

Re: [DWARF] Fix signedness issue in DWARF functions (2)

> 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

Re: [DWARF] Fix signedness issue in DWARF functions (2)

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

Re: [DWARF] dwarf2out cleanups

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

Re: DWARF: Represent hard frame pointer as stack pointer + offset

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

Re: DWARF: Represent hard frame pointer as stack pointer + offset

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

Re: DWARF: Represent hard frame pointer as stack pointer + offset

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

Re: DWARF: Represent hard frame pointer as stack pointer + offset

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

Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info

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

Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info

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

Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info

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

Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info

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

Re: DWARF unwind info is supported on VxWorks

> 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

[wwwdocs] PATCH Re: DWARF Version 5 Standard Released

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

Re: [dwarf, RFC] Emitting per-function dwarf info

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 that

Re: [Dwarf Patch] Use offset into debug_info for pubtype name referring to pubtype section

gcc/ChangeLog 2013-12-02 Sterling Augustine saugust...@google.com * 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.

Re: [Dwarf Patch] Use offset into debug_info for pubtype name referring to pubtype section

On Mon, Dec 2, 2013 at 1:59 PM, Cary Coutant ccout...@google.com 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.

Re: [Dwarf Patch] Generate -ggnu-pubnames

On Thu, Oct 17, 2013 at 12:09 PM, Sterling Augustine saugust...@google.com 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

Re: [Dwarf Patch] Generate -ggnu-pubnames

On Tue, Oct 22, 2013 at 12:05 PM, Sterling Augustine saugust...@google.com wrote: On Thu, Oct 17, 2013 at 12:09 PM, Sterling Augustine saugust...@google.com wrote: The enclosed patch (which depends on http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01395.html), ports the new -ggnu-pubnames

Re: [Dwarf patch] Refactor logic to decide if a pubname should be output.

gcc/ChangeLog 013-07-25 Sterling Augustine saugust...@google.com * 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.

Ping: Re: [DWARF] Fix multiple register spanning location.

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 christian.br...@st.com wrote:

Re: [DWARF] Fix multiple register spanning location.

Christian Bruel christian.br...@st.com 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

Re: [DWARF] Fix multiple register spanning location.

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: Here is a

Re: [DWARF] Fix multiple register spanning location.

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 christian.br...@st.com * dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for

Re: [DWARF] Fix multiple register spanning location.

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 case code

Re: [DWARF] Fix multiple register spanning location.

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 we

Re: [DWARF] Fix multiple register spanning location.

2013-04-26 Christian Bruel christian.br...@st.com * dwarf2out.c (multiple_reg_loc_descriptor): Use DBX_REGISTER_NUMBER for spaning registers. s/spaning/spanning/ Index: dwarf2out.c === --- dwarf2out.c (revision

Re: [Dwarf Patch] Create .debug_str section in .o with -gsplit-dwarf (issue8540048)

2013-04-22 Sterling Augustine saugust...@google.com * 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.

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

On Tue, Nov 6, 2012 at 4:29 PM, Dominique Dhumieres domi...@lps.ens.fr 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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

On Tue, Nov 6, 2012 at 5:02 PM, Dominique Dhumieres domi...@lps.ens.fr 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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

+/* %: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_error (too few

re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

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 compilation

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

On 07/25/2012 07:54 PM, Sterling Augustine wrote: On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant ccout...@google.com 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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

+/* 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't we

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant ccout...@google.com 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

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

+ 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 testing of

Re: [Dwarf Patch] Implement split debug info proposal (issue 6305113)

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.

Re: [Dwarf Patch] Implement split debug info proposal (issue 6305113)

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.

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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 anything more

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

On Tue, May 22, 2012 at 10:19 AM, Jason Merrill ja...@redhat.com 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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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 info is

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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 read

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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. But

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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 from the CU to the

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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):

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

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

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue6197069)

On Thu, May 10, 2012 at 9:08 AM, Sterling Augustine saugust...@google.com 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

Re: DWARF patch to reduce the number of inter-CU refs

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_sibling

Re: DWARF patch to reduce the number of inter-CU refs

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

Re: [dwarf]:

Thanks, committed. (And sorry for the truncated subject). Tristan. On Mar 14, 2012, at 6:50 PM, Jason Merrill wrote: OK. Jason

Re: [Dwarf-Discuss] Vendor extensions in .debug_macinfo

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

Re: [Dwarf-Discuss] Vendor extensions in .debug_macinfo

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

Re: [Dwarf-Discuss] Vendor extensions in .debug_macinfo

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 which

Re: [Dwarf-Discuss] Vendor extensions in .debug_macinfo

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