FAQ
I would like to work on improving the dwarf information generated for go
binaries. In particular I'd like to start with these issues:
https://github.com/golang/go/issues/12899
https://github.com/golang/go/issues/13949

I've looked at these both before and they require more information than is
currently available when generating dwarf.
My big question is, should I be trying to pass this information from the
compiler to the linker (presumably by adding new instructions), or are we
better off moving dwarf generation into the compiler?
Also I don't know anything about the new ssa backend. Does it support dwarf
at all? Does it use the same linker?

-- Ryan Brown

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Matthew Dempsky at Feb 24, 2016 at 7:07 pm

    On Wed, Feb 24, 2016 at 11:01 AM, 'Ryan Brown' via golang-dev wrote:

    Also I don't know anything about the new ssa backend. Does it support
    dwarf at all? Does it use the same linker?
    I can't answer your other questions, but the new SSA-based compiled is
    available in the "dev.ssa" branch: https://github.com/golang/go/tree/dev.ssa

    It definitely uses the same linker, and I'm pretty sure it supports DWARF
    the same as the current compiler does (otherwise the DWARF regress tests
    would be failing).

    Cheers

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Josh Bleecher Snyder at Feb 24, 2016 at 7:14 pm
    [cc Derek]

    I am not the decider, so you should wait for others to weigh in.

    My big question is, should I be trying to pass this information from the
    compiler to the linker (presumably by adding new instructions), or are we
    better off moving dwarf generation into the compiler?
    I think that the best plan is to start by moving dwarf generation into
    the compiler, with no functional changes. Then work on improving it,
    using the SSA backend.

    Also I don't know anything about the new ssa backend. Does it support dwarf
    at all? Does it use the same linker?
    They use the same linker. dwarf generation currently happens entirely
    in the linker. The SSA backend provides approximately the same
    information to the linker that the old backend does.


    The dwarf generation code is currently very inefficient, so hopefully
    at some point in this process it'll also get cleaned up and made more
    efficient--at least, not get any worse or more complicated, so that
    others can help with its efficiency.

    -josh

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Derek Parker at Feb 24, 2016 at 7:35 pm
    I have spoken with Russ (off-list) regarding moving DWARF generation out of
    the linker and into the compiler, and he expressed some hesitation in
    moving in that direction, specifically his response was:
    I would prefer not to move the DWARF code out of the linker, at least not
    what's there today. In particular the file/line number tables are rewritten
    by the linker to reflect the $GOROOT at the time of link, and that's
    important for making binary distributions a bit more relocatable (within
    the file system). Another problem is that Go's fine-grained dead code
    elimination is not well aligned with DWARF's compilation units, unless you
    make every declaration its own compilation unit. I think that the linker
    will necessarily need to stay involved.

    I admit I haven't had to time recently to fully think through solutions,
    but unless we can address those concerns I would say that the best way
    forward, at least for this cycle, would be to improve the information
    provided to the linker from the compiler, and take a look at cleaning up
    and potentially optimizing the DWARF code in the linker.

    Otherwise, if we can come up with solutions to the above concerns I think
    moving the generation into the compiler (specifically the new SSA back end)
    would be the appropriate way to go, as it would prevent duplicate work
    upfront (work to introduce new instructions to pass from compiler to
    linker, etc) that would be removed if/when DWARF generation is moved into
    the compiler.

    Also, Ryan I responded to your off-list mail, but I am very interested in
    helping with this work.
    On Wednesday, February 24, 2016 at 11:01:39 AM UTC-8, Ryan Brown wrote:

    I would like to work on improving the dwarf information generated for go
    binaries. In particular I'd like to start with these issues:
    https://github.com/golang/go/issues/12899
    https://github.com/golang/go/issues/13949

    I've looked at these both before and they require more information than is
    currently available when generating dwarf.
    My big question is, should I be trying to pass this information from the
    compiler to the linker (presumably by adding new instructions), or are we
    better off moving dwarf generation into the compiler?
    Also I don't know anything about the new ssa backend. Does it support
    dwarf at all? Does it use the same linker?

    -- Ryan Brown
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Feb 24, 2016 at 8:41 pm
    I'd like to support this work as well. I don't think I'll have time to
    code on it, but if you have any questions about the compiler generally or
    SSA in particular, I'm happy to help.

    On Wed, Feb 24, 2016 at 11:35 AM, Derek Parker wrote:

    I have spoken with Russ (off-list) regarding moving DWARF generation out
    of the linker and into the compiler, and he expressed some hesitation in
    moving in that direction, specifically his response was:
    I would prefer not to move the DWARF code out of the linker, at least
    not what's there today. In particular the file/line number tables are
    rewritten by the linker to reflect the $GOROOT at the time of link, and
    that's important for making binary distributions a bit more relocatable
    (within the file system). Another problem is that Go's fine-grained dead
    code elimination is not well aligned with DWARF's compilation units, unless
    you make every declaration its own compilation unit. I think that the
    linker will necessarily need to stay involved.

    I admit I haven't had to time recently to fully think through solutions,
    but unless we can address those concerns I would say that the best way
    forward, at least for this cycle, would be to improve the information
    provided to the linker from the compiler, and take a look at cleaning up
    and potentially optimizing the DWARF code in the linker.

    Otherwise, if we can come up with solutions to the above concerns I think
    moving the generation into the compiler (specifically the new SSA back end)
    would be the appropriate way to go, as it would prevent duplicate work
    upfront (work to introduce new instructions to pass from compiler to
    linker, etc) that would be removed if/when DWARF generation is moved into
    the compiler.

    Also, Ryan I responded to your off-list mail, but I am very interested in
    helping with this work.
    On Wednesday, February 24, 2016 at 11:01:39 AM UTC-8, Ryan Brown wrote:

    I would like to work on improving the dwarf information generated for go
    binaries. In particular I'd like to start with these issues:
    https://github.com/golang/go/issues/12899
    https://github.com/golang/go/issues/13949

    I've looked at these both before and they require more information than
    is currently available when generating dwarf.
    My big question is, should I be trying to pass this information from the
    compiler to the linker (presumably by adding new instructions), or are we
    better off moving dwarf generation into the compiler?
    Also I don't know anything about the new ssa backend. Does it support
    dwarf at all? Does it use the same linker?

    -- Ryan Brown
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Austin Clements at Feb 26, 2016 at 3:37 am

    On Wed, Feb 24, 2016 at 2:35 PM, Derek Parker wrote:

    I have spoken with Russ (off-list) regarding moving DWARF generation out
    of the linker and into the compiler, and he expressed some hesitation in
    moving in that direction, specifically his response was:
    I would prefer not to move the DWARF code out of the linker, at least
    not what's there today. In particular the file/line number tables are
    rewritten by the linker to reflect the $GOROOT at the time of link, and
    that's important for making binary distributions a bit more relocatable
    (within the file system). Another problem is that Go's fine-grained dead
    code elimination is not well aligned with DWARF's compilation units, unless
    you make every declaration its own compilation unit. I think that the
    linker will necessarily need to stay involved.

    I admit I haven't had to time recently to fully think through solutions,
    but unless we can address those concerns I would say that the best way
    forward, at least for this cycle, would be to improve the information
    provided to the linker from the compiler, and take a look at cleaning up
    and potentially optimizing the DWARF code in the linker.

    Otherwise, if we can come up with solutions to the above concerns I think
    moving the generation into the compiler (specifically the new SSA back end)
    would be the appropriate way to go, as it would prevent duplicate work
    upfront (work to introduce new instructions to pass from compiler to
    linker, etc) that would be removed if/when DWARF generation is moved into
    the compiler.
    These both seem like reasonably tractable problems to me (though I'm not
    familiar with the details of the linker's DWARF generation). The linker
    should be able to rewrite the file name tables in the line tables easily
    enough to fix $GOROOT. The harder problem is probably dealing with the
    fine-grained dead code elimination. Russ and I chatted about this a bit
    today and he suggested attaching DWARF snippets to each function and type
    and the package as a whole and letting the linker paste these together to
    construct the DWARF compilation units. Of course, the devil's in the
    details, but this seems nicer than constructing the whole CU in the
    compiler and parsing it in the linker to remove dead parts. Things like the
    abbrevs and opcode base are already fixed, so it should be possible to
    paste these snippets together blindly with a little help from relocations.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Derek Parker at Feb 29, 2016 at 11:07 pm
    Just wanted to update: Ryan and I are working together on a proposal to
    address both moving DWARF generation from linker to compiler, as well as
    overall improvements / additions to the DWARF information that is
    generated. There are still some outstanding, potentially unanswered
    questions specifically surrounding moving DWARF generation into the
    compiler, which we will continue to discuss in this thread.
    On Wednesday, February 24, 2016 at 11:01:39 AM UTC-8, Ryan Brown wrote:

    I would like to work on improving the dwarf information generated for go
    binaries. In particular I'd like to start with these issues:
    https://github.com/golang/go/issues/12899
    https://github.com/golang/go/issues/13949

    I've looked at these both before and they require more information than is
    currently available when generating dwarf.
    My big question is, should I be trying to pass this information from the
    compiler to the linker (presumably by adding new instructions), or are we
    better off moving dwarf generation into the compiler?
    Also I don't know anything about the new ssa backend. Does it support
    dwarf at all? Does it use the same linker?

    -- Ryan Brown
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedFeb 24, '16 at 7:01p
activeFeb 29, '16 at 11:07p
posts7
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase