[Bug testsuite/32261] New: [RFE] Script that turns .S debug information into dwarf::assembler style

[Bug testsuite/32261] New: [RFE] Script that turns .S debug information into dwarf::assembler style

[guinevere at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

            Bug ID: 32261
           Summary: [RFE] Script that turns .S debug information into
                    dwarf::assembler style
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: guinevere at redhat dot com
  Target Milestone: ---

TL;DR: It would be nice if GDB had a script (I imagine in python) that could be
fed a .S file with debug information, and the script would output a TCL file
that had valid Dwarf::Assembler syntax, so that we could quickly convert old
style file, and maybe use it with new tests to speed up development.

For some context, GDB often has to test very specific situations in DWARF
information, that sometimes can only be generated with specific compilers or
compiler versions. The most consistent way to test those is to define the debug
information by hand when creating the test. This used to be done by committing
a .S file with the desired state, but some years ago a better way to do it was
introduced, called the Dwarf Assembler.

With the assembler, we are able to write debug information in a somewhat human
readable format, to help in reviewing what is being tested and in case we need
to fudge the information in ways that only show up in very complex projects
(like having non-contiguous ranges for functions). The full syntax for the
assembler is defined in gdb/testsuite/lib/dwarf.exp. Some tests in the
gdb/testsuite/gdb.dwarf2 folder use this new syntax

The old tests were never converted to the new format, but rather than doing it
manually, it would be nice if there was a script that could receive the old
file and output something with the new format. Old tests can be mostly found in
the folder gdb/testsuite/gdb.dwarf2, and they are identified by having a .S
file.

Another problem of the assembler is that the syntax is not always intuitive, so
it's often time consuming to write a new test from scratch. This script could
be used when a small reproducer is enough or almost enough to trigger a bug, so
that it is a lot easier and faster to write new tests.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[guinevere at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

Guinevere Larsen <guinevere at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |good-first-bug

--- Comment #1 from Guinevere Larsen <guinevere at redhat dot com> ---
Marking this as a good first bug because I think there's little GDB specific
knowledge required, just scripting and DWARF knowledge.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #2 from Simon Marchi <simon.marchi at polymtl dot ca> ---
That's a really good idea.

I'm not sure if that's what you had in mind, but in my mind such a script would
use a binary with actual DWARF debug info in it as an input, it would not try
to parse the .S file. But it could perhaps assemble the .S to a .o for you, if
you passed it a .S, before processing the .o.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[guinevere at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #3 from Guinevere Larsen <guinevere at redhat dot com> ---
Either-or is fine.

I think if it used .o or a fully compiled binary it may be easier to parse when
we're looking at new tests, but it would be harder to create the script, while
parsing the .S you can probably use the hints from comments, and just in
general sounds easier to me, but I'm happy with either version

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #4 from Simon Marchi <simon.marchi at polymtl dot ca> ---
I think that parsing the DWARF using something like pyelftools is relatively
straightforward (more than parsing an assembly text file).  And one use case
for such a tool would be to generate a test case from a binary that someone
uploaded on Bugzilla, for which we don't have the source code, for instance.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
I've long thought about a readelf option to generate something
similar to DWARF assembler output.

The main issue I guess is that you'd normally want to take
the output and remove a lot of the extraneous gunk.  It can
just be done by hand though.

(In reply to Simon Marchi from comment #4)
> I think that parsing the DWARF using something like pyelftools is relatively
> straightforward (more than parsing an assembly text file).

Even easier than a readelf patch, so +1 to that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[guinevere at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #6 from Guinevere Larsen <guinevere at redhat dot com> ---
(In reply to Tom Tromey from comment #5)
> I've long thought about a readelf option to generate something
> similar to DWARF assembler output.
> 
> The main issue I guess is that you'd normally want to take
> the output and remove a lot of the extraneous gunk.  It can
> just be done by hand though.

Yeah, I do expect that most outputs would need some level of hand-removal of
gunk, if for no other reason than all tests I create nowadays are usually not
actually generating the DWARF I need, but they look like they could.

> 
> (In reply to Simon Marchi from comment #4)
> > I think that parsing the DWARF using something like pyelftools is relatively
> > straightforward (more than parsing an assembly text file).
> 
> Even easier than a readelf patch, so +1 to that.

+1 from me too. My idea of parsing things by hand was definitely unnecessary
lol

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

William Ferreira <wqferr at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wqferr at gmail dot com

--- Comment #7 from William Ferreira <wqferr at gmail dot com> ---
I'm interested in taking this on, but I have no experience manipulating or
reading DWARF files. Guinevere is a friend of mine and she has stated she's
willing to help me, but additional sources of information would be welcome.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to William Ferreira from comment #7)
> I'm interested in taking this on, but I have no experience manipulating or
> reading DWARF files. Guinevere is a friend of mine and she has stated she's
> willing to help me, but additional sources of information would be welcome.

The Python tool that Simon suggested is:
https://github.com/eliben/pyelftools

There's a sample program that reads & dumps the DWARF here:
https://github.com/eliben/pyelftools/blob/main/scripts/dwarfdump.py

Copying that verbatim isn't ok for something that goes in the gdb
repo but you can use it to understand the API at least.
I gather that the docs for this library are in the source and
not (AFAIK) published on the web somewhere.

The goal would be to read DWARF and then spit out a representation
which is reasonably close to what is accepted by the test suite's
"DWARF assembler".  This is a Tcl library that takes a high-ish
level representation of DWARF and generates assembly.

The code for the DWARF assembler is here:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/lib/dwarf.exp;hb=HEAD

There's some comments explaining how to use it.  Look for the
line starting "namespace eval Dwarf" -- there are some comments
just before this, but also more inline in that namespace.

There are also many example tests using it in the test suite,
mostly in the "gdb.dwarf2" subdirectory.  E.g.,
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/gdb.dwarf2/missing-type-name.exp;hb=HEAD

Search for "Dwarf::assemble" in that file to see what
the "assembly" format looks like.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #9 from William Ferreira <wqferr at gmail dot com> ---
I appreciate the help. I have a personal project launching next Wednesday so I
will probably delay until after then to start work on this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #10 from William Ferreira <wqferr at gmail dot com> ---
I come here looking for help; I am confused with regards to some features of
the Dwarf assembler.

In line 503 of gdb.dwarf2/dwarf.exp, it states:

If VALUE starts with the ":" character, then it is a label
    reference.  The rest of VALUE is taken to be the name of a label,
    and DW_FORM_ref4 is used.  See 'new_label' and 'define_label'.

But in line 55 of gdb.dwarf2/dynarr-ptr.exp, I find:

{DW_AT_type :$integer_label}

Where both the : prefix for a label value and the TCL variable expansion symbol
$ are used. From my understanding of the documentation pasted above, the
correct usage would have been:

{DW_AT_type :integer_label}

Since integer_label is a label declared previously in the file.

Could someone explain to me what I am missing, please?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #11 from William Ferreira <wqferr at gmail dot com> ---
I'm progressing quite quickly on the problem. I probably won't have it ready by
the end of the year, but I don't expect it to take much longer.

I've adopted the previous comment's questions as cargo cult dogma for now. I
also have no idea how TUs are encoded in Dwarf::assemble code, so I'll leave
them for later (or leave them out, if that's an option).

Are there any other DIEs that can appear at top-level besides TUs and CUs?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #12 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to William Ferreira from comment #11)

> Are there any other DIEs that can appear at top-level besides TUs and CUs?

There's DW_TAG_partial_unit, which is like a CU.
It's fine for any such tool to be incomplete at the start.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #13 from William Ferreira <wqferr at gmail dot com> ---
I return with good news! The program finally outputs valid TCL code. It doesn't
include the copyright notice at the top yet, but it should be very easy to do.

One major missing feature is that subprogram high and low PCs are hardcoded.
That's going to be the next implemented feature.

For now, here is an example output, ran with the compiled output of the
gdb.dwarf2/dw2-entry-value test.


# Program output starts here
load_lib dwarf.exp
require dwarf2_support
set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
    global srcdir subdir srcfile
    declare_labels int
    cu {} {
        DW_TAG_compile_unit {} {
            DW_TAG_subprogram {
                {DW_AT_name f DW_FORM_string}
                {DW_AT_low_pc 4198662}
                {DW_AT_high_pc 4198687}
                {DW_AT_prototyped True}
            }
            DW_TAG_base_type {
                {DW_AT_name param DW_FORM_string}
                {DW_AT_type :$int}
                {DW_AT_location 0}
            }
            int: DW_TAG_base_type {
                {DW_AT_name int DW_FORM_string}
                {DW_AT_byte_size 4}
                {DW_AT_encoding 5}
            }
        }
    }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to William Ferreira from comment #13)
> I return with good news! The program finally outputs valid TCL code. It
> doesn't include the copyright notice at the top yet, but it should be very
> easy to do.

There's helper code in gdb for this, see gdb/gdbcopyright.py.

> One major missing feature is that subprogram high and low PCs are hardcoded.
> That's going to be the next implemented feature.

FWIW the test suite has some specialized code for this.
Search the dwarf tests for "get_func_info", or read it
directly in lib/dwarf.exp.

> For now, here is an example output, ran with the compiled output of the
> gdb.dwarf2/dw2-entry-value test.

Awesome.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #15 from William Ferreira <wqferr at gmail dot com> ---
I also want to remove the number literals from {DW_AT_encoding 5} and the like,
but I'll leave that for later. I'll have a look at the copyright thing and the
function you suggested.

Thanks, I'll keep you updated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #16 from William Ferreira <wqferr at gmail dot com> ---
Is there a list of TCL keywords I need to avoid? All I could find (in a quick
search, I will admit) is a list of TCL built-in commands, but no keyword list
like you can find in C. Can I use those as Dwarf::assemble labels? What about
variable names?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #17 from Tom Tromey <tromey at sourceware dot org> ---
Tcl does not really have keywords per se -- everything, including
flow-control things like "if", is just a procedure.

Labels in the DWARF assembler are variables, not procs.
Variables and procs have separate namespaces in Tcl so can share
a name.  The exception is that making a DWARF label makes
a proc with the same name but a trailing colon.

For generating labels, though, I think something generic
is fine, like "die" plus the hex section offset.
Often these aren't interesting; and anyway can be edited
by hand if desirable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to William Ferreira from comment #15)
> I also want to remove the number literals from {DW_AT_encoding 5} and the
> like, but I'll leave that for later. 

FWIW the DWARF assembler creates its tables and such by
scanning include/dwarf2.{h,def}.  Your script could do similarly,
though the associate between DW_AT_* and other constants
(like "encoding" uses DW_ATE_* constants) isn't specified here
and would have to be done manually.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #19 from William Ferreira <wqferr at gmail dot com> ---
Is the conversion from integers to @DW_ATE_* wanted? It will be a little bit of
complexity (not much) to add, but if deemed not necessary I might as well not
bother.

In other notes, pyelftools doesn't seem to decode DW_OP_* into a usable format.
When running the dynarr-ptr.exp's assembled elf back into the script I'm
writing, this segment:

            array_label: DW_TAG_array_type {
                {DW_AT_name foo__array_type}
                {DW_AT_type :$integer_label}
                {external 1 flag}
            } {
                DW_TAG_subrange_type {
                    {DW_AT_type        :$integer_label}
                    {DW_AT_lower_bound {
                        DW_OP_push_object_address
                        DW_OP_const1u [expr {2 * $int_size}]
                        DW_OP_minus
                        DW_OP_deref_size $int_size
                    } SPECIAL_expr}
                    {DW_AT_upper_bound {
                        DW_OP_push_object_address
                        DW_OP_const1u $int_size
                        DW_OP_minus
                        DW_OP_deref_size $int_size
                    } SPECIAL_expr}
                }
            }

Becomes this:

            foo_array_type: DW_TAG_array_type {
                {DW_AT_name foo__array_type DW_FORM_string}
                {DW_AT_type :$integer DW_FORM_ref4}
                {DW_AT_external 1 DW_FORM_flag}
            } {
                DW_TAG_subrange_type {
                    {DW_AT_type :$integer DW_FORM_ref4}
                    {DW_AT_lower_bound {151 8 8 28 148 4} DW_FORM_exprloc}
                    {DW_AT_upper_bound {151 8 4 28 148 4} DW_FORM_exprloc}
                }
            }

Note the array of integers for DW_AT_lower_bound and DW_AT_upper_bound. Unlike
most other data in the DWARF format, pyelftools simply ignores the meaning of
DW_OP_* and gives them to me "raw".

I'm not sure how to proceed with this, or if this tentative solution is even
valid as is. I'm not particularly keen on decoding these operations myself, but
if it must be done I will warn that it may take some time for me to finish
implementing it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #20 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to William Ferreira from comment #19)
> Is the conversion from integers to @DW_ATE_* wanted? It will be a little bit
> of complexity (not much) to add, but if deemed not necessary I might as well
> not bother.

It would be nice to have but I think it's not really needed for the MVP.
It's fine for things to land without every desirable feature.  We did this
with the DWARF assembler itself.

> In other notes, pyelftools doesn't seem to decode DW_OP_* into a usable
> format.

> I'm not sure how to proceed with this, or if this tentative solution is even
> valid as is. I'm not particularly keen on decoding these operations myself,
> but if it must be done I will warn that it may take some time for me to
> finish implementing it.

I am not sure but I tend to doubt it will work as-is with the DWARF assembler.
Some change there might be needed, or you might have to write your own
expression parser.  This isn't outrageously hard.

Also, is this something you're planning to land in the gdb tree?
Personally I'd think that makes the most sense, since the output
is tailored to gdb's test suite's DWARF assembler.  In order to do
this we'd need a copyright assignment though... you may want to get
started on that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[wqferr at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #21 from William Ferreira <wqferr at gmail dot com> ---
(In reply to Tom Tromey from comment #20)

> I am not sure but I tend to doubt it will work as-is with the DWARF
> assembler.
> Some change there might be needed, or you might have to write your own
> expression parser.  This isn't outrageously hard.

Alright, I'll do my best then.

> Also, is this something you're planning to land in the gdb tree?
> Personally I'd think that makes the most sense, since the output
> is tailored to gdb's test suite's DWARF assembler.  In order to do
> this we'd need a copyright assignment though... you may want to get
> started on that.

Guinevere mentioned something about giving the copyright to the entirety of my
work to the FSF. Is that what this is about? I'm completely fine with it, I
just don't know where to get started.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #22 from Mark Wielaard <mark at klomp dot org> ---
(In reply to William Ferreira from comment #21)
> (In reply to Tom Tromey from comment #20)
> > Also, is this something you're planning to land in the gdb tree?
> > Personally I'd think that makes the most sense, since the output
> > is tailored to gdb's test suite's DWARF assembler.  In order to do
> > this we'd need a copyright assignment though... you may want to get
> > started on that.
> 
> Guinevere mentioned something about giving the copyright to the entirety of
> my work to the FSF. Is that what this is about? I'm completely fine with it,
> I just don't know where to get started.

See https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright
You want to fill out request-assign.future and sent it to assign@gnu.org
to get the process started.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[guinevere at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #23 from Guinevere Larsen <guinevere at redhat dot com> ---
(In reply to Tom Tromey from comment #20)
> (In reply to William Ferreira from comment #19)
> > In other notes, pyelftools doesn't seem to decode DW_OP_* into a usable
> > format.
> 
> > I'm not sure how to proceed with this, or if this tentative solution is even
> > valid as is. I'm not particularly keen on decoding these operations myself,
> > but if it must be done I will warn that it may take some time for me to
> > finish implementing it.
> 
> I am not sure but I tend to doubt it will work as-is with the DWARF
> assembler.
> Some change there might be needed, or you might have to write your own
> expression parser.  This isn't outrageously hard.
> 

I was chatting to William and I don't think it is reasonable to have the final
script outputting the DW_AT_location. Not necessarily because parsing location
expressions is that hard, but because the location will be built on top of
information from other symbols that may not be available for the script to use.

Take gdb.dwarf2/dynarr-ptr.exp for example. To calculate the DW_OP_addr values,
it uses the gdb_target_symbol to get the actual location into which the
variable was compiled. The script, having only access to the final compiled
binary, will not have any clue where this address came from. The 2 symbols that
that test uses to set those addresses (table_1_ptr and table_2_ptr) aren't even
compiled into the final debuginfo, so if the script were to guess one source it
wouldn't even be able to guess correctly.

I know that some location expressions would work, but then we have an even
worse situation (IMO) where the location is partially supported and I think
people might forget to fix it by hand in the cases where it doesn't.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/32261] [RFE] Script that turns .S debug information into dwarf::assembler style

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32261

--- Comment #24 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Guinevere Larsen from comment #23)
> (In reply to Tom Tromey from comment #20)
> > (In reply to William Ferreira from comment #19)
> I was chatting to William and I don't think it is reasonable to have the
> final script outputting the DW_AT_location. Not necessarily because parsing
> location expressions is that hard, but because the location will be built on
> top of information from other symbols that may not be available for the
> script to use.

That seems totally fine.
Some hand editing will probably always be needed anyway, I'd guess.

Anyway I think the best thing is to get some kind of MVP in the tree.
Then we can add features as needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.