https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
--- Comment #14 from jakub at gcc dot gnu dot org 2010-04-21 16:49 ---
Subject: Bug 40040
Author: jakub
Date: Wed Apr 21 16:48:41 2010
New Revision: 158612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158612
Log:
PR debug/40040
* dwarf2out.c (add_name_and_src_c
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:46
---
I have googled the gcc.gnu.org domain for my name and DW_AT_MIPS_linkage_name,
and came up with nothing relevant. So, I never proposed or sought to get this
part approved, which confirms it's probably just human
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-21 10:43 ---
Yeah, that's exactly the hunk I'm referring to. The gdb patch Jan provided
relies on DW_AT_MIPS_linkage_name (or DW_AT_linkage_name hopefully for DWARF4)
to be provided. While for most normal Fortran identifiers whe
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:38
---
(In reply to comment #10)
> Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
> could find any discussions about it on the mailing list from that time.
In the bugzilla PR you reference,
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 10:31 ---
BTW, gcc stopped emitting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129882
- PR10220 commit.
Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
could find any discussions about it
--- Comment #9 from jan dot kratochvil at redhat dot com 2010-04-20 12:24
---
(In reply to comment #8)
> BTW, should DW_AT_{,MIPS_}linkage_name be also present on DW_TAG_common_block?
[...]
> for DW_AT_linkage_name to be allowed on DW_TAG_common_block.
For DW_TAG_common_block:
+ /
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-20 09:21 ---
Please treat DW_AT_linkage_name the same as DW_AT_MIPS_linkage_name, for
-gdwarf-4 the patch I've posted yesterday emits the former rather than latter.
Currently the addition of DW_AT_{,MIPS_}linkage_name is guarded w
--- Comment #7 from jan dot kratochvil at redhat dot com 2010-04-20 09:14
---
Created an attachment (id=20436)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20436&action=view)
Preliminary GDB patch.
Tobias, could you add DW_AT_MIPS_linkage name?
You say in Comment 3 the debugger
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-21 18:40 ---
What is actually the status of this PR? I read through it twice and I still do
not know whether this is a GCC bug or a GNU ld bug - and, if the former, how it
is supposed to be fixed.
--
http://gcc.gnu.org/bugzil
--- Comment #5 from jan dot kratochvil at redhat dot com 2009-05-06 20:12
---
(In reply to comment #4)
> I don't know how ready GDB et al are to cope with this,
(For GDB the local definitions containing an address expression are even less
problematic than the current declarations requi
--- Comment #4 from roland at redhat dot com 2009-05-06 19:45 ---
Hmm. I am concerned by the idea of relocs for DWARF sections in final-linked
objects. That is a hassle that consumers have not had to handle before.
(AFAIK only consumers that handle ET_REL pseudo-final objects such as
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'. As GDB also has to know the C++ mangling rules I
> believe this Fortran mangling i
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-05-06 10:54
---
(In reply to comment #1)
> If DW_AT_location isn't provided, how would gdb find that address out? Using
> DW_AT_MIPS_linkage_name (currently not emitted) and symbol lookup?
The GDB patch now assembles the sy
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-06 10:24 ---
I'd say this is actually a ld bug, not GCC.
GCC emits:
.uleb128 0x3# (DIE (0x38) DW_TAG_variable)
.ascii "var\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (pr40040lib.f90)
.byt
16 matches
Mail list logo
