--- 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
--- 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 c
--- 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, he
--- 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 sen
--- 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 `acces
--- 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 20:39
t for undefined variables
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pj dot pandit at yahoo dot co dot in
