[LLVMdev] Proposal: add Go frontend subproject based on llgo

[Ian Taylor]

On Thu, Nov 20, 2014 at 12:46 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Thu, Nov 20, 2014 at 03:16:49PM +0100, Joerg Sonnenberger wrote:
>> On Wed, Nov 19, 2014 at 04:58:08PM -0800, Peter Collingbourne wrote:
>> > On Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote:
>> > > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote:
>> > > > llgo depends on certain third-party components, namely a copy of the Go
>> > > > standard library (libgo), a Go program analysis library (go.tools) and two
>> > > > library dependencies of the standard library (libbacktrace and libffi).
>> > >
>> > > I think providing a better alternative to libffi is already a goal of
>> > > some people, but what is libbacktrace needed for? What is not provided
>> > > by the Itanium Unwind ABI?
>> >
>> > According to the libbacktrace readme file:
>> >
>> > > As of September 2012, libbacktrace only supports ELF executables with
>> > > DWARF debugging information.  The library is written to make it
>> > > straightforward to add support for other object file and debugging
>> > > formats.
>>
>> My question still stands. Do you use it for nice backtraces in debugging
>> situations?
>
> It appears so.

(Again I am missing the context here.)

Yes, but not only for that.  libgo also uses the libbacktrace library
to implement the Go standard library function runtime.Caller, and
associated functions like runtime.Callers, runtime.FuncForPC,
runtime.Stack, etc.

(For runtime.Caller see http://golang.org/pkg/runtime/#Caller).

These functions are used for various purposes other than debugging.
For example, the log package uses them.

The libbacktrace library is also used for certain complex cases in
Go's panic/recover mechanism.

Basically it is impossible to implement to fully implement Go with
libgo without something like libbacktrace.

Ian