> 1. Do any of the Intel compilers still generate DW_OP_INTEL_bit_piece=0xe8?
> (John DelSignore)
I am still at Intel; I'll ask the debug-info guys and reply later.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfst
> So what about these structures makes them difficult to describe in DWARF?
> Let each producer define structures that work for them.
Fortran defines the TEAM_TYPE as "processor dependent", which means
implementation is up to the compiler/run-time implementation. It could be a
pointer to a str
I am no longer a committee member, but I am still involved with helping make
Fortran debuggable. I ask for comments on the possible extension described
below.
Fortran now has an extensive set of features to support parallel program using
a shared-memory paradigm. This was introduced in the 2
All,
I will take this as my cue to retire from the DWARF Committee.
When I joined many years ago, I was working on a debugger. For the last
several years I've been maintaining and enhancing a Fortran run-time library.
As a result, debugger issues and DWARF are not part of my work-life and I c
> (1) What if the user chose the first of these options and the program
> changed the variable multiple times between lines 112 and 120?
That's a user error (or misunderstanding), just as in the case where the code
was far simpler:
Line Source
10A = 10
11A = 11
12B = A
...an
With split lifetimes, the debugger can ask the user which of the lifetimes the
user wants to set.
debugger-prompt> set A = 3
Variable 'A' has more than one location. Choose which to set:
1. The location used in lines 112 and 120
2. The location used in line 111
3. All loc
My suggestion is to create a new location list of valid L-value locations.
Thus the issues would be addressed:
- where the variable doesn't exist, there would be no L-value listed;
- where two variables share the same location, there would be no L-value listed;
- where the variable is in two or
Intel Fortran uses DW_TAG_entry_point as well, and shows "a" as a parameter to
foo() and "b" as a parameter to alt entry point bar().
-John Bishop
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo
> For example, add a new attribute, e.g., DW_AT_source, and in 3.1.1 where
> DW_AT_name is described:
However we point to the source code, we'd want to be able to do PC/line
correlation; the line number table currently uses the source file name and the
line (and column) numbers; the proposal sh
--[ quote ]--
I'm writing this email in particular to address the problem of referencing
source files in DWARF for online-compiled programs. The issue is that
programming models such as OpenCL can often have source generated at
runtime,which is compiled online, with its output not written to fi
Question: Would it be permissible to create a DW_TAG_imported_declaration
for a DW_TAG_namelist with an empty DW_TAG_namelist_item list and rely on
the compiler to fetch the namelist items from the module's DW_TAG_namelist?
I think if you are importing, you don't even need the DW_TAG_name
> Maybe DWARF needs a DW_FORM_data16.
Rather than one-plus to get data16 (soon we'd need data32, etc), I think you
should use DW_FORM_block1. If consumers make invalid assumptions, we shouldn't
change DWARF to compensate for that.
I first thought of suggesting that we add words to the effect t
12 matches
Mail list logo