Re: [go-nuts] CGO core dump analysis using GDB

[mariappan balraj]

Hi Ian,

Thanks for your continuous support. GOLANG supports CGO to invoke C
functions. When it is supported, the important thing is, it should provide
better debugging support when there is any issue. In customer sites, it is
not possible to run applications with GDB. Customers only provide core dump
and logs. With the provided information, we should be able to debug the
issue. It may not be possible to reproduce all the issues in the
development environment to debug the issue.

When we run the application with GDB, we are getting stack trace. Then the
same thing should be possible with core dump also.

I have tried with CGO symbolizer from
https://github.com/ianlancetaylor/cgosymbolizer. I am getting the following
output. This is useful. But I want to dump the C variables (local and
global) to debug the issue. This is very critical when we want to debug
some issues.

What should I do now? How to proceed further? If possible, please provide
your help with this.

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x463926]

runtime stack:
runtime.throw({0x49046b?, 0x0?})
/usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffca8644230
sp=0x7ffca8644200 pc=0x43243d
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7ffca8644280
sp=0x7ffca8644230 pc=0x446569

goroutine 1 [syscall]:
test1
/home/ubuntu/mbalraj/GO/TEST/test.go:9 pc=0x463926
test2
/home/ubuntu/mbalraj/GO/TEST/test.go:14 pc=0x46393b
test3
/home/ubuntu/mbalraj/GO/TEST/test.go:18 pc=0x46394b
_cgo_64d258852278_Cfunc_test3
/tmp/go-build/cgo-gcc-prolog:49 pc=0x46396b
runtime.asmcgocall
/usr/local/go/src/runtime/asm_amd64.s:844 pc=0x45c443
runtime.cgocall(0x46394f, 0xc58f70)
/usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc58f48
sp=0xc58f10 pc=0x40579c
main._Cfunc_test3()
_cgo_gotypes.go:41 +0x45 fp=0xc58f70 sp=0xc58f48 pc=0x463885
main.main()
/home/ubuntu/mbalraj/GO/TEST/test.go:26 +0x17 fp=0xc58f80
sp=0xc58f70 pc=0x4638b7
runtime.main()
/usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc58fe0
sp=0xc58f80 pc=0x434c92
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc58fe8
sp=0xc58fe0 pc=0x45c761

Best Regards
Mariappan

On Sat, Jan 7, 2023 at 9:45 AM Ian Lance Taylor  wrote:

> On Fri, Jan 6, 2023, 5:57 PM mariappan balraj 
> wrote:
>
>> Hi Ian,
>> Thanks for your active help. When I run the program by using gdb, I am
>> getting the complete stack. No issue. The issue is there when we debug core
>> dump. Could you kindly please check whether you are seeing the same
>> behavior with core dump?
>>
>
>
> Oh, right, sorry, I forgot about the core dump part.  I don't know if
> there is a way to make that better, given the three different stacks
> involved.  I'm surprised that it works as well as it does.  A pure C
> program that doesn't use sigaltstack only has a single stack, so it's a
> much simpler case.
>
> Ian
>
>
>
> On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor,  wrote:
>>
>>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
>>>  wrote:
>>> >
>>> > I am not expecting GO stack. I am interested only in getting C stack.
>>> If I want go stack, I can use delve debugger to get it. From GO, using CGO,
>>> test3() is called which is calling test2() which is calling test1(). I am
>>> expecting only C stack which contains test3(),  test2(), test1(). In this
>>> particular case assigning value by using pointer variable which contains
>>> NULL(segmentation fault). I am seeing only test1(). After that it is not
>>> stack and saying stack corruption. I strongly believe that you can help on
>>> this. Please help.
>>>
>>> I put your program in foo.go.  Then I did:
>>>
>>> > CGO_CFLAGS=-g go build foo.go
>>> > gdb ./foo
>>> GNU gdb (Debian 12.1-3) 12.1
>>> Copyright (C) 2022 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <
>>> http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> .
>>> Find the GDB manual and other documentation resources online at:
>>> .
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from ./foo...
>>> warning: File "/home/iant/go/src/runtime/runtime-gdb.py" auto-loading
>>> has been declined by your `auto-load safe-path' set to
>>> "$debugdir:$datadir/auto-load".
>>> To enable execution of this file add
>>> add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py
>>> line to your configuration file "/home/iant/.config/gdb/gdbinit".
>>> To completely disable this security 

Re: [go-nuts] CGO core dump analysis using GDB

[Ian Lance Taylor]

On Fri, Jan 6, 2023, 5:57 PM mariappan balraj 
wrote:

> Hi Ian,
> Thanks for your active help. When I run the program by using gdb, I am
> getting the complete stack. No issue. The issue is there when we debug core
> dump. Could you kindly please check whether you are seeing the same
> behavior with core dump?
>


Oh, right, sorry, I forgot about the core dump part.  I don't know if there
is a way to make that better, given the three different stacks involved.
I'm surprised that it works as well as it does.  A pure C program that
doesn't use sigaltstack only has a single stack, so it's a much simpler
case.

Ian



On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor,  wrote:
>
>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
>>  wrote:
>> >
>> > I am not expecting GO stack. I am interested only in getting C stack.
>> If I want go stack, I can use delve debugger to get it. From GO, using CGO,
>> test3() is called which is calling test2() which is calling test1(). I am
>> expecting only C stack which contains test3(),  test2(), test1(). In this
>> particular case assigning value by using pointer variable which contains
>> NULL(segmentation fault). I am seeing only test1(). After that it is not
>> stack and saying stack corruption. I strongly believe that you can help on
>> this. Please help.
>>
>> I put your program in foo.go.  Then I did:
>>
>> > CGO_CFLAGS=-g go build foo.go
>> > gdb ./foo
>> GNU gdb (Debian 12.1-3) 12.1
>> Copyright (C) 2022 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from ./foo...
>> warning: File "/home/iant/go/src/runtime/runtime-gdb.py" auto-loading
>> has been declined by your `auto-load safe-path' set to
>> "$debugdir:$datadir/auto-load".
>> To enable execution of this file add
>> add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py
>> line to your configuration file "/home/iant/.config/gdb/gdbinit".
>> To completely disable this security protection add
>> set auto-load safe-path /
>> line to your configuration file "/home/iant/.config/gdb/gdbinit".
>> For more information about this security protection see the
>> --Type  for more, q to quit, c to continue without paging--
>> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
>> shell:
>> info "(gdb)Auto-loading safe path"
>> (gdb) r
>> Starting program: /tmp/x/foo
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffd09ea640 (LWP 650585)]
>> [New Thread 0x7fffcbfff640 (LWP 650586)]
>> [New Thread 0x7fffcb7fe640 (LWP 650587)]
>> [New Thread 0x7fffcaffd640 (LWP 650588)]
>> [New Thread 0x7fffca7fc640 (LWP 650589)]
>>
>> Thread 1 "foo" received signal SIGSEGV, Segmentation fault.
>> 0x0045b01a in test1 () at /home/iant/foo.go:6
>> 6*p = 30;
>> (gdb) where
>> #0  0x0045b01a in test1 () at /home/iant/foo.go:6
>> #1  0x0045b02c in test2 () at /home/iant/foo.go:10
>> #2  0x0045b038 in test3 () at /home/iant/foo.go:14
>> #3  0x0045b054 in _cgo_3060c004c901_Cfunc_test3 (v=0xc64f70)
>> at /tmp/go-build/cgo-gcc-prolog:49
>> #4  0x00456c64 in runtime.asmcgocall ()
>> at /home/iant/go/src/runtime/asm_amd64.s:848
>> #5  0x004e3460 in ?? ()
>> #6  0x0001 in ?? ()
>> #7  0x00c80500 in ?? ()
>> #8  0x7fffe458 in ?? ()
>> #9  0x00439225 in runtime.malg.func1 ()
>> at /home/iant/go/src/runtime/proc.go:4227
>> #10 0x00456aa9 in runtime.systemstack ()
>> at /home/iant/go/src/runtime/asm_amd64.s:496
>> #11 0x004596a5 in runtime.newproc (fn=0x1) at :1
>> #12 0x004cc720 in runtime[scavenger] ()
>> #13 0x0001 in ?? ()
>> #14 0x004569a5 in runtime.mstart ()
>> at /home/iant/go/src/runtime/asm_amd64.s:394
>> #15 0x0045692f in runtime.rt0_go ()
>> at /home/iant/go/src/runtime/asm_amd64.s:358
>> #16 0x0001 in ?? ()
>> --Type  for more, q to quit, c to continue without paging--q
>> Quit
>>
>>
>>
>> So when I try it, I do see the full C stack at the point where the
>> signal occurs.
>>
>> In your backtrace earlier you are trying to see the stack after the
>> signal is already being handled by the Go signal handler.  I don't
>> know why that would work.
>>
>> Ian
>>
>

-- 
You 

Re: [go-nuts] CGO core dump analysis using GDB

[mariappan balraj]

Hi Ian,
Thanks for your active help. When I run the program by using gdb, I am
getting the complete stack. No issue. The issue is there when we debug core
dump. Could you kindly please check whether you are seeing the same
behavior with core dump?

Best Regards
Mariappan

On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor,  wrote:

> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
>  wrote:
> >
> > I am not expecting GO stack. I am interested only in getting C stack. If
> I want go stack, I can use delve debugger to get it. From GO, using CGO,
> test3() is called which is calling test2() which is calling test1(). I am
> expecting only C stack which contains test3(),  test2(), test1(). In this
> particular case assigning value by using pointer variable which contains
> NULL(segmentation fault). I am seeing only test1(). After that it is not
> stack and saying stack corruption. I strongly believe that you can help on
> this. Please help.
>
> I put your program in foo.go.  Then I did:
>
> > CGO_CFLAGS=-g go build foo.go
> > gdb ./foo
> GNU gdb (Debian 12.1-3) 12.1
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./foo...
> warning: File "/home/iant/go/src/runtime/runtime-gdb.py" auto-loading
> has been declined by your `auto-load safe-path' set to
> "$debugdir:$datadir/auto-load".
> To enable execution of this file add
> add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py
> line to your configuration file "/home/iant/.config/gdb/gdbinit".
> To completely disable this security protection add
> set auto-load safe-path /
> line to your configuration file "/home/iant/.config/gdb/gdbinit".
> For more information about this security protection see the
> --Type  for more, q to quit, c to continue without paging--
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
> shell:
> info "(gdb)Auto-loading safe path"
> (gdb) r
> Starting program: /tmp/x/foo
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffd09ea640 (LWP 650585)]
> [New Thread 0x7fffcbfff640 (LWP 650586)]
> [New Thread 0x7fffcb7fe640 (LWP 650587)]
> [New Thread 0x7fffcaffd640 (LWP 650588)]
> [New Thread 0x7fffca7fc640 (LWP 650589)]
>
> Thread 1 "foo" received signal SIGSEGV, Segmentation fault.
> 0x0045b01a in test1 () at /home/iant/foo.go:6
> 6*p = 30;
> (gdb) where
> #0  0x0045b01a in test1 () at /home/iant/foo.go:6
> #1  0x0045b02c in test2 () at /home/iant/foo.go:10
> #2  0x0045b038 in test3 () at /home/iant/foo.go:14
> #3  0x0045b054 in _cgo_3060c004c901_Cfunc_test3 (v=0xc64f70)
> at /tmp/go-build/cgo-gcc-prolog:49
> #4  0x00456c64 in runtime.asmcgocall ()
> at /home/iant/go/src/runtime/asm_amd64.s:848
> #5  0x004e3460 in ?? ()
> #6  0x0001 in ?? ()
> #7  0x00c80500 in ?? ()
> #8  0x7fffe458 in ?? ()
> #9  0x00439225 in runtime.malg.func1 ()
> at /home/iant/go/src/runtime/proc.go:4227
> #10 0x00456aa9 in runtime.systemstack ()
> at /home/iant/go/src/runtime/asm_amd64.s:496
> #11 0x004596a5 in runtime.newproc (fn=0x1) at :1
> #12 0x004cc720 in runtime[scavenger] ()
> #13 0x0001 in ?? ()
> #14 0x004569a5 in runtime.mstart ()
> at /home/iant/go/src/runtime/asm_amd64.s:394
> #15 0x0045692f in runtime.rt0_go ()
> at /home/iant/go/src/runtime/asm_amd64.s:358
> #16 0x0001 in ?? ()
> --Type  for more, q to quit, c to continue without paging--q
> Quit
>
>
>
> So when I try it, I do see the full C stack at the point where the
> signal occurs.
>
> In your backtrace earlier you are trying to see the stack after the
> signal is already being handled by the Go signal handler.  I don't
> know why that would work.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKKWi6TaVDmb%3Dz%2BjM0%3DRqyz0OAiJV1j6q97_N3pwbo89BOpdjA%40mail.gmail.com.

Re: [go-nuts] CGO core dump analysis using GDB

[Ian Lance Taylor]

On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
 wrote:
>
> I am not expecting GO stack. I am interested only in getting C stack. If I 
> want go stack, I can use delve debugger to get it. From GO, using CGO, 
> test3() is called which is calling test2() which is calling test1(). I am 
> expecting only C stack which contains test3(),  test2(), test1(). In this 
> particular case assigning value by using pointer variable which contains 
> NULL(segmentation fault). I am seeing only test1(). After that it is not 
> stack and saying stack corruption. I strongly believe that you can help on 
> this. Please help.

I put your program in foo.go.  Then I did:

> CGO_CFLAGS=-g go build foo.go
> gdb ./foo
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./foo...
warning: File "/home/iant/go/src/runtime/runtime-gdb.py" auto-loading
has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py
line to your configuration file "/home/iant/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/iant/.config/gdb/gdbinit".
For more information about this security protection see the
--Type  for more, q to quit, c to continue without paging--
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) r
Starting program: /tmp/x/foo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffd09ea640 (LWP 650585)]
[New Thread 0x7fffcbfff640 (LWP 650586)]
[New Thread 0x7fffcb7fe640 (LWP 650587)]
[New Thread 0x7fffcaffd640 (LWP 650588)]
[New Thread 0x7fffca7fc640 (LWP 650589)]

Thread 1 "foo" received signal SIGSEGV, Segmentation fault.
0x0045b01a in test1 () at /home/iant/foo.go:6
6*p = 30;
(gdb) where
#0  0x0045b01a in test1 () at /home/iant/foo.go:6
#1  0x0045b02c in test2 () at /home/iant/foo.go:10
#2  0x0045b038 in test3 () at /home/iant/foo.go:14
#3  0x0045b054 in _cgo_3060c004c901_Cfunc_test3 (v=0xc64f70)
at /tmp/go-build/cgo-gcc-prolog:49
#4  0x00456c64 in runtime.asmcgocall ()
at /home/iant/go/src/runtime/asm_amd64.s:848
#5  0x004e3460 in ?? ()
#6  0x0001 in ?? ()
#7  0x00c80500 in ?? ()
#8  0x7fffe458 in ?? ()
#9  0x00439225 in runtime.malg.func1 ()
at /home/iant/go/src/runtime/proc.go:4227
#10 0x00456aa9 in runtime.systemstack ()
at /home/iant/go/src/runtime/asm_amd64.s:496
#11 0x004596a5 in runtime.newproc (fn=0x1) at :1
#12 0x004cc720 in runtime[scavenger] ()
#13 0x0001 in ?? ()
#14 0x004569a5 in runtime.mstart ()
at /home/iant/go/src/runtime/asm_amd64.s:394
#15 0x0045692f in runtime.rt0_go ()
at /home/iant/go/src/runtime/asm_amd64.s:358
#16 0x0001 in ?? ()
--Type  for more, q to quit, c to continue without paging--q
Quit



So when I try it, I do see the full C stack at the point where the
signal occurs.

In your backtrace earlier you are trying to see the stack after the
signal is already being handled by the Go signal handler.  I don't
know why that would work.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWVnx%3DgtKx9%2BwQ%3D%2B3RW78yg-EA922CD1Sf6B_9vCG9HaQ%40mail.gmail.com.

Re: [go-nuts] CGO core dump analysis using GDB

[mariappan balraj]

Hi Ian,

I am not expecting GO stack. I am interested only in getting C stack. If I
want go stack, I can use delve debugger to get it. From GO, using CGO,
test3() is called which is calling test2() which is calling test1(). I am
expecting only C stack which contains test3(),  test2(), test1(). In this
particular case assigning value by using pointer variable which contains
NULL(segmentation fault). I am seeing only test1(). After that it is not
stack and saying stack corruption. I strongly believe that you can help on
this. Please help.


Best regards
Mariappan

On Sat, 7 Jan, 2023, 12:12 am Ian Lance Taylor,  wrote:

> On Thu, Jan 5, 2023 at 10:39 PM mariappan balraj
>  wrote:
> >
> > When I call the same function from pure C code, I am able to get the
> complete stack and it is not reporting that the stack is corrupted. I am
> expecting the same C stack when I use CGO also. Please kindly help with
> this.
>
> C code and Go code run on different stacks.  As I tried to explain
> earlier, gdb does not have enough information to unwind from a C stack
> to a Go stack.
>
> What you are looking for simply doesn't work.  Sorry.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKKWi6STx%2BXNYfG3srky_8YpnqOTaC62n6UzNr3C2s%3Dhds460Q%40mail.gmail.com.

Re: [go-nuts] CGO core dump analysis using GDB

[Ian Lance Taylor]

On Thu, Jan 5, 2023 at 10:39 PM mariappan balraj
 wrote:
>
> When I call the same function from pure C code, I am able to get the complete 
> stack and it is not reporting that the stack is corrupted. I am expecting the 
> same C stack when I use CGO also. Please kindly help with this.

C code and Go code run on different stacks.  As I tried to explain
earlier, gdb does not have enough information to unwind from a C stack
to a Go stack.

What you are looking for simply doesn't work.  Sorry.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWyB1iJXZLCx722QKgOp4Tr-g670saGSz2DGbiKhoDRmA%40mail.gmail.com.

Re: [go-nuts] Which tool provide's the Go playground's import handling...

['Mark' via golang-nuts]

Thanks, that's just what I needed :-)

On Friday, January 6, 2023 at 8:21:02 AM UTC kortschak wrote:

> On Fri, 2023-01-06 at 00:13 -0800, 'Mark' via golang-nuts wrote:
> > If I visit the Go playground and change the body of `main()` to, say,
> > `fmt.Println("hello", math.Abs(-5))` and then click Run, the `import
> > "fmt"` line is _automatically_ corrected to be `import
> > (\n\t"fmt"\n\t"math"\n)`. I'd like to be able to use this
> > functionality so that I can set my editor to do "fiximports" and then
> > "gofmt" rather than just "gofmt" as now. But I don't know what the
> > tool is that does this?
>
> https://pkg.go.dev/golang.org/x/tools/cmd/goimports
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0a0d14e9-b1ed-4bef-8785-5ca29778b332n%40googlegroups.com.

Re: [go-nuts] Which tool provide's the Go playground's import handling...

['Dan Kortschak' via golang-nuts]

On Fri, 2023-01-06 at 00:13 -0800, 'Mark' via golang-nuts wrote:
> If I visit the Go playground and change the body of `main()` to, say,
> `fmt.Println("hello", math.Abs(-5))` and then click Run, the `import
> "fmt"` line is _automatically_ corrected to be `import
> (\n\t"fmt"\n\t"math"\n)`. I'd like to be able to use this
> functionality so that I can set my editor to do "fiximports" and then
> "gofmt" rather than just "gofmt" as now. But I don't know what the
> tool is that does this?

https://pkg.go.dev/golang.org/x/tools/cmd/goimports

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e22cea931c01b89503d46af6db7a2a2c48e11445.camel%40kortschak.io.

[go-nuts] Which tool provide's the Go playground's import handling...

['Mark' via golang-nuts]

If I visit the Go playground  and change the body of 
`main()` to, say, `fmt.Println("hello", math.Abs(-5))` and then click Run, 
the `import "fmt"` line is _automatically_ corrected to be `import 
(\n\t"fmt"\n\t"math"\n)`. I'd like to be able to use this functionality so 
that I can set my editor to do "fiximports" and then "gofmt" rather than 
just "gofmt" as now. But I don't know what the tool is that does this?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9d6b1181-6332-492b-a9cc-93b8953882bfn%40googlegroups.com.