Comment 1:

yeah, this is an interesting task.
i suggest we switch to DWARF, so that we don't need an extra copy of
DWARF just for gdb.
are there any readily usable DWARF reader with BSD license?

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 2:

For reading line number information, not types: gcc/libbacktrace.  It's in the GCC
source code but it's under a BSD license.

Comment 3:

can we afford to use it in our runtime library?
how big is it?

Comment 4:

It would take some adjustment for the gc runtime library, of course (I already use it in
the gccgo runtime library).  The DWARF reading code is 3000 lines and compiles to 18,685
bytes on amd64 when compiled with GCC when optimizing.  That includes some error
handling and some generality that may not be necessary.  The ELF reading code, which is
probably unnecessary, is 900 lines, 4269 bytes.

Comment 5:

There's a dwarf reader in plan9port too, integrated into its copy of
libmach.

Comment 6:

Labels changed: removed go1.1maybe.

Comment 7:

Labels changed: added go1.3maybe.

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

Comment 9:

Labels changed: added repo-main.

Comment 10:

FWIW we could use the new PC-associated data to store info about inlined functions. I
don't know what will be the amount of duplicated info, though.

Does this happen to be on anyone's radar for 1.8 or 1.9? Or is this a low-priority feature request?

More aggressive inlining would certainly give a large performance boost to a lot of constructs. For example, inlining thunk functions (#8421) and inlining functions that can't inline all the way down (@dr2chase comment in #11189). The last one would certainly help me in one spot: https://github.com/tdewolff/buffer/blob/master/lexer.go#L158, which is a function that is called very often but only sometimes calls the costly read function. Peek would increase performance for the parsers using this library by 10%-20%, which is a lot!

As far as I know, this is now fixed (see proposals 19348 and 22080). Closing, please re-open if needed.