--- Comment #8 from roland at redhat dot com 2010-08-13 08:08 ---
I think you've confused static variables (file scope) with C++ static members
(global scope). At any rate, this is not the place to get an education about
DWARF. You can use the dwarf-discuss mailing list for those
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-13 08:48 ---
Thus, INVALID.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pj dot pandit at yahoo dot co dot in 2010-08-13 10:37
---
I think we've stepped away from DW_AT_external.
This global linkage theory is not convincing for why DW_AT_external should be
set for variables/functions that are defined outside of the compilation unit.
--- Comment #11 from redi at gcc dot gnu dot org 2010-08-13 10:51 ---
But surely if (as you suggest) swscanf had a DIE without DW_AT_external that
would imply it was private to the compilation unit, which would be wrong.
If a non-static function has a DIE, it should include
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-13 10:57
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-13 11:05 ---
(In reply to comment #7)
Also, how does on locate the DIEs for variables/functions that are listed in
the .debug_pubnames section($ eu-readelf -wpubnames file). The list of
variables/functions that are *defined* in
--- Comment #14 from pj dot pandit at yahoo dot co dot in 2010-08-13 13:14
---
But surely if (as you suggest) swscanf had a DIE without DW_AT_external that
would imply it was private to the compilation unit, which would be wrong.
Hmmn...may be.
DW_AT_specification tells you it's
--- Comment #6 from roland at redhat dot com 2010-08-13 00:43 ---
DW_AT_external is correct for anything that has global linkage, whether or
not is defined. The absence of DW_AT_external, in a DIE that is not inside a
DW_TAG_subprogram scope, means that it has file linkage, like a
--- Comment #7 from pj dot pandit at yahoo dot co dot in 2010-08-13 05:52
---
You got me confused. What do you mean - DW_AT_external is correct for anything
that has global linkage, whether or not is defined. - ?
How do you define global linkage, here?
DIEs for static
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-11 09:27 ---
I don't see why any change is needed. If a function (or variable) isn't
defined in the current translation unit, then it necessarily has to be
accessible from outside of the translation unit containing it.
--
--- Comment #3 from pj dot pandit at yahoo dot co dot in 2010-08-11 12:15
---
DW_AT_external is meant to indicate whether a variable/function, that is
defined in the compilation unit, is accessible/visible from the outside of it
or not.
It's a subtle difference between `accessible
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-11 12:46 ---
I don't see the standard saying that anywhere.
A DW_AT_external attribute, which is a flag, if the name of a variable is
visible outside of its enclosing compilation unit.
If the name of the subroutine described by
--- Comment #5 from pj dot pandit at yahoo dot co dot in 2010-08-12 05:30
---
Doesn't the wording - visible outside of its containing compilation unit - ring
any bells?
Secondly, for variables and functions that are not defined in the compilation
unit, it doesn't make sense to mark
--- Comment #1 from pj dot pandit at yahoo dot co dot in 2010-08-02 18:38
---
The following patch to gcc-4.4.4 seems to fix the issue for DW_AT_subprogram
DIEs.
$ diff -Naurp gcc-4.4.4/gcc/dwarf2out.c gcc-4.4.4.1/gcc/dwarf2out.c
--- gcc-4.4.4/gcc/dwarf2out.c 2010-02-10
14 matches
Mail list logo
