Created attachment 991800 [details] A bit hacky fix Description of problem: https://sourceware.org/gdb/wiki/GoDebugging#golang_Wrong_DW_TAG_variable golang provides &name variable names and the DWARF interface uses one more pointer than in the source. Version-Release number of selected component (if applicable): golang-1.4.1-1.fc22.x86_64 How reproducible: Always. Steps to Reproduce: ------------------- package main func main () { var i int ip:=&i ipp:=&ip go func() { **ipp++ }() } ------------------- Actual results: (gdb) b 8 (gdb) r (gdb) p i No symbol "i" in current context. (gdb) p &i No symbol "i" in current context. (gdb) p '&i' Invalid character constant. (gdb) p ' &i' $1 = (int *) 0xc20800a080 (gdb) p *' &i' $2 = 0 (gdb) p ' &ip' $3 = (int **) 0xc20803a000 (gdb) p *' &ip' $4 = (int *) 0xc20800a080 (gdb) p **' &ip' $5 = 0 (gdb) p ' &ipp' $6 = (int ***) 0xc20803a008 (gdb) p *' &ipp' $7 = (int **) 0xc20803a000 (gdb) p **' &ipp' $8 = (int *) 0xc20800a080 (gdb) p ***' &ipp' $9 = 0 Expected results: (gdb) b 8 (gdb) r (gdb) p i $1 = (int &) @0xc20800a080: 0 (gdb) p ip $2 = (int *&) @0xc20803a000: 0xc20800a080 (gdb) p *ip $3 = 0 (gdb) p ipp $4 = (int **&) @0xc20803a008: 0xc20803a000 (gdb) p *ipp $5 = (int *) 0xc20800a080 (gdb) p **ipp $6 = 0 (gdb) whatis i type = int & (gdb) whatis ip type = int *& (gdb) whatis ipp type = int **& Additional info: But you said golang upstream is writing some new linker so maybe this hack is not much relevant for upstream. DW_AT_name of the reference types is IMO incorrect but I do not think it matters much for GDB; for 'ipp' with this patch there is: <fe78> DW_AT_name : &(***int)
BTW that DW_AT_name should not be there at all for such DW_TAG_reference_type, according to DWARF spec: If a name has been given to the modified type in the source program, then the corresponding modified type entry has a DW_AT_name attribute whose value is a null-terminated string containing the modified type name as it appears in the source program.
so here is a comparison of your reproduction on latest stable (go1.4.2) and master (c25c371 / go1.5-dev) go version go1.4.2 linux/amd64 (gdb) b 8 Breakpoint 1 at 0x400c8e: /home/vbatts/bz1192742/bz1192742.go:8. (2 locations) (gdb) r Starting program: /home/vbatts/bz1192742/bz1192742 Breakpoint 1, main.main () at /home/vbatts/bz1192742/bz1192742.go:8 8 }() (gdb) p i No symbol "i" in current context. (gdb) p &i No symbol "i" in current context. (gdb) p ' &i' $1 = (int *) 0xc20800a080 (gdb) p *' &i' $2 = 0 (gdb) p ' &ip' $3 = (int **) 0xc20803c000 (gdb) p *' &ip' $4 = (int *) 0xc20800a080 (gdb) p **' &ip' $5 = 0 (gdb) p ' &ipp' $6 = (int ***) 0xc20803c008 (gdb) p *' &ipp' $7 = (int **) 0xc20803c000 (gdb) p **' &ipp' $8 = (int *) 0xc20800a080 (gdb) p ***' &ipp' $9 = 0 (gdb) whatis ' &i' type = int * (gdb) whatis ' &ip' type = int ** (gdb) whatis ' &ipp' type = int ** go version devel +c25c371 Thu Feb 19 17:00:30 2015 +0000 linux/amd64 (gdb) b 8 Breakpoint 1 at 0x400c66: /home/vbatts/bz1192742/bz1192742.go:8. (2 locations) (gdb) r Starting program: /home/vbatts/bz1192742/bz1192742 Breakpoint 1, main.main () at /home/vbatts/bz1192742/bz1192742.go:8 8 }() (gdb) p i No symbol "i" in current context. (gdb) p &i No symbol "i" in current context. (gdb) p ' &i' $1 = (int *) 0xc20800a080 (gdb) p *' &i' $2 = 0 (gdb) p ' &ip' $3 = (int **) 0xc20801e008 (gdb) p *' &ip' $4 = (int *) 0xc20800a080 (gdb) p **' &ip' $5 = 0 (gdb) p ' &ipp' No symbol " &ipp" in current context. (gdb) p *' &ipp' No symbol " &ipp" in current context. (gdb) p **' &ipp' No symbol " &ipp" in current context. (gdb) p ***' &ipp' No symbol " &ipp" in current context. (gdb) whatis ' &i' type = int * (gdb) whatis ' &ip' type = int ** (gdb) whatis ' &ipp' No symbol " &ipp" in current context.
= The only difference is that 'ipp' is missing there completely. Apparently 'ipp' has been optimized out, it took me some tuning of the example code to keep it small and prevent 'ipp' being optimized out, apparently new golang needs a bit more complicated usage of the variable to keep it in place. I do not think the specific testcase is a major issue in this Bug but thanks for the notice I should update the testcase. I am not sure if you are going to accept it as a downstream patch in Fedora and/or if I should submit it upstream myself.
(In reply to Jan Kratochvil from comment #1) > BTW that DW_AT_name should not be there at all for such > DW_TAG_reference_type, according to DWARF spec: > > If a name has been given to the modified type in the source program, then > the corresponding modified type entry has a DW_AT_name attribute whose value > is a null-terminated string containing the modified type name as it appears > in the source program. so, the following should not reference 'ipp' ?: <2><86>: Abbrev Number: 5 (DW_TAG_formal_parameter) <87> DW_AT_name : ipp <8b> DW_AT_location : 1 byte block: 9c (DW_OP_call_frame_cfa) <8d> DW_AT_type : <0x1951b>
(In reply to Jan Kratochvil from comment #3) > I am not sure if you are going to accept it as a downstream patch in Fedora > and/or if I should submit it upstream myself. I've just been looking for issues related to this upstream. https://github.com/golang/go/issues Something like this we should work with them upstream first.
(In reply to Vincent Batts from comment #4) > so, the following should not reference 'ipp' ?: A different case: <2><40>: Abbrev Number: 4 (DW_TAG_variable) <41> DW_AT_name : &ipp <46> DW_AT_location : 4 byte block: 9c 11 60 22 (DW_OP_call_frame_cfa; DW_OP_consts: -32; DW_OP_plus) <4b> DW_AT_type : <0xe45a> <1><e45a>: Abbrev Number: 17 (DW_TAG_pointer_type) <e45b> DW_AT_name : ***int <e462> DW_AT_type : <0xe46b> <e46a> Unknown AT value: 2900: 22 <1><e46b>: Abbrev Number: 17 (DW_TAG_pointer_type) <e46c> DW_AT_name : **int <e472> DW_AT_type : <0xe47b> <e47a> Unknown AT value: 2900: 22 [...] Only this line should be omitted: <e45b> DW_AT_name : ***int Because there is no triple-pointer in the .go source, it is only internal implementation detail how golang has compiled it. With my patch this DIE <1><e45a>: Abbrev Number: 17 (DW_TAG_pointer_type) <e45b> DW_AT_name : ***int <e462> DW_AT_type : <0xe46b> <e46a> Unknown AT value: 2900: 22 is replaced by this DIE: <1><fe77>: Abbrev Number: 18 (DW_TAG_reference_type) <fe78> DW_AT_name : &(***int) <fe82> DW_AT_type : <0xe462> <fe8a> Unknown AT value: 2900: 22 But still this line should be in fact omitted for DWARF compliance: <fe78> DW_AT_name : &(***int)
(In reply to Vincent Batts from comment #5) > I've just been looking for issues related to this upstream. > https://github.com/golang/go/issues OK, there are some open DWARF issues. > Something like this we should work with them upstream first. You said the 'linker' is going to be replaced by something new but I expect for RH Go development it still makes sense to patch the current 'linker' instance.
https://go-review.googlesource.com/#/c/7150/ is the upstream change review
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.