* gdb compile for powerpc64 target - Could not find symbol ".TOC." @ 2021-06-22 18:54 will schmidt 2021-06-23 15:36 ` Ulrich Weigand 0 siblings, 1 reply; 13+ messages in thread From: will schmidt @ 2021-06-22 18:54 UTC (permalink / raw) To: Ulrich Weigand, gdb-patches; +Cc: rogerio, Carl E. Love Hi, I've been looking at the gdb-compile tests on a powerpc64le target. In particular the testsuite/gdb.compile/compile-print.exp test. I've locally made a change to set a ppc64le_gnu_triplet_regexp value of "powerpc64le?" to allow gdb to actually find the compiler and libcc1 for this platform. With this change the simplest tests are successful, i.e. gdb_test "compile print main" gdb_test "compile print/x 256" However, anything more complex will fail. i.e. gdb_test "compile print varint" During gdb/compile/compile-object-load.c: compile-object-load() the following is emitted: warning: Could not find symbol ".TOC." for compiled module "/tmp/gdbobj-wIKWtk/out15.o". My best guess is that we need to incorporate some amount of special handling for the TOC entry to help find the symbols we are after. But.. I havn't stumbled across anything similar for other targets, and I havn't yet gleamed enlightenment looking at the existing code in compile-object-load. :-) As a hack I have tried treating the TOC symbol like we do the GOT entry, those attempts will later crash as we will trip over a zero dereference when trying to get at the symbol to print it. With "set debug compile" enabled, a few bits of possibly relevant info.. COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux' '-A' 'system=unix' '-A' 'system=posix' '-msecure-plt' '-mcpu=power8' '-g' '-fstack-protector-strong' '-std=gnu11' '-fno-exceptions' '-Wno-implicit-function-declaration' '-O0' '-gdwarf-4' '-fPIE' '-Wall' '-Wno-unused-but-set-variable' '-Wno-unused-variable' '-fno-stack-protector' '-fplugin=libcc1plugin' '-fplugin-arg-libcc1plugin-fd=14' '-c' '-o' '/tmp/gdbobj-wIKWtk/out18.o' '-v' The compiled code (objdump -d out*.o) looks like so: 0000000000000008 <_gdb_expr>: 8: f8 ff 4c e8 ld r2,-8(r12) c: 14 62 42 7c add r2,r2,r12 10: f8 ff e1 fb std r31,-8(r1) 14: b1 ff 21 f8 stdu r1,-80(r1) 18: 78 0b 3f 7c mr r31,r1 1c: 30 00 7f f8 std r3,48(r31) 20: 38 00 9f f8 std r4,56(r31) 24: 00 00 22 3d addis r9,r2,0 28: 00 00 29 e9 ld r9,0(r9) 2c: 02 00 29 e9 lwa r9,0(r9) 30: 20 00 3f 91 stw r9,32(r31) 34: 20 00 5f 81 lwz r10,32(r31) 38: 38 00 3f e9 ld r9,56(r31) 3c: 00 00 49 91 stw r10,0(r9) 40: 00 00 00 60 nop 44: 50 00 3f 38 addi r1,r31,80 48: f8 ff e1 eb ld r31,-8(r1) 4c: 20 00 80 4e blr ... I do see the iteration of symbols in compile-object-load(), these appear to match the (readelf) section header names as indexed by the (readelf) .symtab table entries. ala: ... ELF symbol "out18.c" flags [4005] ELF symbol ".text" flags [1000105] ELF symbol ".toc" flags [1000105] ELF symbol ".debug_info" flags [1000105] ELF symbol ".debug_abbrev" flags [1000105] ELF symbol ".debug_line" flags [1000105] ELF symbol ".debug_str" flags [1000105] ELF symbol ".debug_frame" flags [1000105] ELF symbol "_gdb_expr" flags [a] ELF symbol ".TOC." flags [0] Per "readelf -a" against the generated .o file, i can see: Symbol table '.symtab' contains 11 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS out5.c 2: 0000000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 5 4: 0000000000000000 0 SECTION LOCAL DEFAULT 6 5: 0000000000000000 0 SECTION LOCAL DEFAULT 8 6: 0000000000000000 0 SECTION LOCAL DEFAULT 11 7: 0000000000000000 0 SECTION LOCAL DEFAULT 13 8: 0000000000000000 0 SECTION LOCAL DEFAULT 16 9: 0000000000000008 84 FUNC GLOBAL DEFAULT [<localentry>: 8] 1 _gdb_expr 10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND .TOC. Relocation section '.rela.text' at offset 0x6a8 contains 4 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000a0000002c R_PPC64_REL64 0000000000000000 .TOC. - 8 000000000008 000000000076 R_PPC64_ENTRY 0 000000000024 000300000032 R_PPC64_TOC16_HA 0000000000000000 .toc + 0 000000000028 000300000040 R_PPC64_TOC16_LO_ 0000000000000000 .toc + 0 Any hints or advice on how to chase this further are welcomed. Thanks -Will ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-22 18:54 gdb compile for powerpc64 target - Could not find symbol ".TOC." will schmidt @ 2021-06-23 15:36 ` Ulrich Weigand 2021-06-23 17:37 ` will schmidt 0 siblings, 1 reply; 13+ messages in thread From: Ulrich Weigand @ 2021-06-23 15:36 UTC (permalink / raw) To: will schmidt, amodra; +Cc: gdb-patches, rogerio, Carl E. Love On Tue, Jun 22, 2021 at 01:54:56PM -0500, will schmidt wrote: > During gdb/compile/compile-object-load.c: > compile-object-load() the following is emitted: > warning: Could not find symbol ".TOC." for compiled module > "/tmp/gdbobj-wIKWtk/out15.o". > > My best guess is that we need to incorporate some amount of special > handling for the TOC entry to help find the symbols we are after. > But.. I havn't stumbled across anything similar for other targets, and > I havn't yet gleamed enlightenment looking at the existing code in > compile-object-load. :-) As a hack I have tried treating the > TOC symbol like we do the GOT entry, those attempts will later crash as > we will trip over a zero dereference when trying to get at the symbol > to print it. Yes, we probably do need a proper value for .TOC. Usually, this is set by the linker to 0x8000 bytes after the beginning of the .toc section, I think. Looks like there is a BFD routine ppc64_elf_set_toc that will define that symbol, but that's probably never called here if you just load a plain object file. Alan, do you have any suggestions of how to handle this, maybe? > With "set debug compile" enabled, a few bits of possibly relevant > info.. > > COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux' Can you try without -mcmodel=large ? The particular reference to the .TOC. symbol you show below originated from this option. However, even without that there may still be references to .TOC. Bye, Ulricj -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-23 15:36 ` Ulrich Weigand @ 2021-06-23 17:37 ` will schmidt 2021-06-24 3:11 ` Alan Modra 0 siblings, 1 reply; 13+ messages in thread From: will schmidt @ 2021-06-23 17:37 UTC (permalink / raw) To: Ulrich Weigand, amodra; +Cc: gdb-patches, rogerio, Carl E. Love On Wed, 2021-06-23 at 17:36 +0200, Ulrich Weigand wrote: > On Tue, Jun 22, 2021 at 01:54:56PM -0500, will schmidt wrote: > > > During gdb/compile/compile-object-load.c: > > compile-object-load() the following is emitted: > > warning: Could not find symbol ".TOC." for compiled module > > "/tmp/gdbobj-wIKWtk/out15.o". > > > > My best guess is that we need to incorporate some amount of special > > handling for the TOC entry to help find the symbols we are after. > > But.. I havn't stumbled across anything similar for other targets, > > and > > I havn't yet gleamed enlightenment looking at the existing code in > > compile-object-load. :-) As a hack I have tried treating the > > TOC symbol like we do the GOT entry, those attempts will later > > crash as > > we will trip over a zero dereference when trying to get at the > > symbol > > to print it. > > Yes, we probably do need a proper value for .TOC. Usually, this > is set by the linker to 0x8000 bytes after the beginning of the .toc > section, I think. > > Looks like there is a BFD routine ppc64_elf_set_toc that will define > that symbol, but that's probably never called here if you just load > a plain object file. > > Alan, do you have any suggestions of how to handle this, maybe? > > > > With "set debug compile" enabled, a few bits of possibly relevant > > info.. > > > > COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux' > > Can you try without -mcmodel=large ? The particular reference to > the .TOC. symbol you show below originated from this option. > However, even without that there may still be references to .TOC. Yes.. without specifying mcmodel (defaults to medium?) same result. Also just tried with each of large,medium,small in turn.. same results. Thanks -Will > > Bye, > Ulricj > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-23 17:37 ` will schmidt @ 2021-06-24 3:11 ` Alan Modra 2021-06-24 4:39 ` Alan Modra 2021-06-24 15:32 ` Ulrich Weigand 0 siblings, 2 replies; 13+ messages in thread From: Alan Modra @ 2021-06-24 3:11 UTC (permalink / raw) To: will schmidt; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Wed, Jun 23, 2021 at 12:37:48PM -0500, will schmidt wrote: > On Wed, 2021-06-23 at 17:36 +0200, Ulrich Weigand wrote: > > On Tue, Jun 22, 2021 at 01:54:56PM -0500, will schmidt wrote: > > > > > During gdb/compile/compile-object-load.c: > > > compile-object-load() the following is emitted: > > > warning: Could not find symbol ".TOC." for compiled module > > > "/tmp/gdbobj-wIKWtk/out15.o". > > > > > > My best guess is that we need to incorporate some amount of special > > > handling for the TOC entry to help find the symbols we are after. > > > But.. I havn't stumbled across anything similar for other targets, > > > and > > > I havn't yet gleamed enlightenment looking at the existing code in > > > compile-object-load. :-) As a hack I have tried treating the > > > TOC symbol like we do the GOT entry, those attempts will later > > > crash as > > > we will trip over a zero dereference when trying to get at the > > > symbol > > > to print it. I'm not at all familiar with gdb/compile, but it looks like anything to do with the GOT is unsupported. I can't see any handling for GOT relocs, for example. Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but compile-object-load.c is just broken, I think. You can't set .TOC. or _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, for code that uses those symbols. > > > > Yes, we probably do need a proper value for .TOC. Usually, this > > is set by the linker to 0x8000 bytes after the beginning of the .toc > > section, I think. Again, I'm not familiar enough with the gdb compile support to give proper advice. If calls to functions in the newly compiled/loaded code is always via global entry points then you have some freedom in choosing your own .TOC. value. If direct calls to the local entry point are made then .TOC. should be set to the value used in whatever context is going to call the newly loaded object. That would be tricky. Oh, and another thing, even if you manage to set a value for .TOC., bfd_get_relocated_section_contents uses reloc howtos to perform relocations. bfd.c:_bfd_get_gp_value is used for all the TOC16 relocs, which means elf_gp should be set to .TOC. and you can't leave the bfd format as bfd_object. > > Looks like there is a BFD routine ppc64_elf_set_toc that will define > > that symbol, but that's probably never called here if you just load > > a plain object file. > > > > > > > Alan, do you have any suggestions of how to handle this, maybe? > > > > > > > With "set debug compile" enabled, a few bits of possibly relevant > > > info.. > > > > > > COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux' > > > > Can you try without -mcmodel=large ? The particular reference to > > the .TOC. symbol you show below originated from this option. > > However, even without that there may still be references to .TOC. > > Yes.. without specifying mcmodel (defaults to medium?) same result. > Also just tried with each of large,medium,small in turn.. same results. > > > > > Thanks > -Will > > > > > Bye, > > Ulricj > > -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-24 3:11 ` Alan Modra @ 2021-06-24 4:39 ` Alan Modra 2021-06-24 15:32 ` Ulrich Weigand 1 sibling, 0 replies; 13+ messages in thread From: Alan Modra @ 2021-06-24 4:39 UTC (permalink / raw) To: will schmidt; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > relocations. bfd.c:_bfd_get_gp_value is used for all the TOC16 > relocs, which means elf_gp should be set to .TOC. and you can't leave > the bfd format as bfd_object. Ignore that remark about bfd_object. I had it backwards. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-24 3:11 ` Alan Modra 2021-06-24 4:39 ` Alan Modra @ 2021-06-24 15:32 ` Ulrich Weigand 2021-06-24 23:05 ` Alan Modra 1 sibling, 1 reply; 13+ messages in thread From: Ulrich Weigand @ 2021-06-24 15:32 UTC (permalink / raw) To: Alan Modra; +Cc: gdb-patches, will schmidt, rogerio, Carl E. Love On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > I'm not at all familiar with gdb/compile, but it looks like anything > to do with the GOT is unsupported. I can't see any handling for GOT > relocs, for example. The basic approach seems to be: - Allocate memory in the inferior for each section - Use bfd_set_section_vma on all sections to provide the address - Load the symbol table via bfd_canonicalize_symtab - Modify the symbol table to provide values for all undefined symbols (via GDB looking them up in the rest of the inferior) - Use bfd_get_relocated_section_contents to load the contents of all sections, using the symbol table from above I think the assumption is that bfd_get_relocated_section_contents will handle any relocation type, including GOT/TOC relocs. > Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but > compile-object-load.c is just broken, I think. You can't set .TOC. or > _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, for > code that uses those symbols. Agreed, it looks like this makes the Intel-specific assumption that code uses PC-relative addressing for everything and does not actually rely on the value of _GLOBAL_OFFSET_TABLE_. I'm not sure this is even completely true for Intel, but it certainly isn't on Power. > > > Yes, we probably do need a proper value for .TOC. Usually, this > > > is set by the linker to 0x8000 bytes after the beginning of the .toc > > > section, I think. > > Again, I'm not familiar enough with the gdb compile support to give > proper advice. If calls to functions in the newly compiled/loaded > code is always via global entry points then you have some freedom in > choosing your own .TOC. value. If direct calls to the local entry > point are made then .TOC. should be set to the value used in whatever > context is going to call the newly loaded object. That would be > tricky. Inferior calls should always use the global entry point, so that should be OK. I'm more concerned that we have to use the same value for .TOC. as will be used by bfd_get_relocated_section_contents for handling TOC-relative relocations. If we just define a value for the .TOC. symbol in the symbol table passed to bfd_get_relocated_section_contents, will this be used? If so, that might be the easiest fix; simply provide a reasonable value (e.g. address of the .toc section + 0x8000) in the symbol table, and everything else ought to work out ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-24 15:32 ` Ulrich Weigand @ 2021-06-24 23:05 ` Alan Modra 2021-06-25 14:49 ` will schmidt 2021-07-09 16:51 ` will schmidt 0 siblings, 2 replies; 13+ messages in thread From: Alan Modra @ 2021-06-24 23:05 UTC (permalink / raw) To: Ulrich Weigand; +Cc: gdb-patches, will schmidt, rogerio, Carl E. Love On Thu, Jun 24, 2021 at 05:32:50PM +0200, Ulrich Weigand wrote: > On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > > > I'm not at all familiar with gdb/compile, but it looks like anything > > to do with the GOT is unsupported. I can't see any handling for GOT > > relocs, for example. > > The basic approach seems to be: > - Allocate memory in the inferior for each section > - Use bfd_set_section_vma on all sections to provide the address > - Load the symbol table via bfd_canonicalize_symtab > - Modify the symbol table to provide values for all undefined symbols > (via GDB looking them up in the rest of the inferior) > - Use bfd_get_relocated_section_contents to load the contents of > all sections, using the symbol table from above > > I think the assumption is that bfd_get_relocated_section_contents > will handle any relocation type, including GOT/TOC relocs. > > > Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but > > compile-object-load.c is just broken, I think. You can't set .TOC. or > > _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, for > > code that uses those symbols. > > Agreed, it looks like this makes the Intel-specific assumption that > code uses PC-relative addressing for everything and does not actually > rely on the value of _GLOBAL_OFFSET_TABLE_. I'm not sure this is > even completely true for Intel, but it certainly isn't on Power. > > > > > Yes, we probably do need a proper value for .TOC. Usually, this > > > > is set by the linker to 0x8000 bytes after the beginning of the .toc > > > > section, I think. > > > > Again, I'm not familiar enough with the gdb compile support to give > > proper advice. If calls to functions in the newly compiled/loaded > > code is always via global entry points then you have some freedom in > > choosing your own .TOC. value. If direct calls to the local entry > > point are made then .TOC. should be set to the value used in whatever > > context is going to call the newly loaded object. That would be > > tricky. > > Inferior calls should always use the global entry point, so that > should be OK. I'm more concerned that we have to use the same > value for .TOC. as will be used by bfd_get_relocated_section_contents > for handling TOC-relative relocations. If we just define a value > for the .TOC. symbol in the symbol table passed to > bfd_get_relocated_section_contents, will this be used? No, just defining .TOC. won't be sufficient. A .TOC. symbol value is used if the symbol is found in the linker hash table, but here we aren't even invoking the linker. I think the gdb code should call _bfd_set_gp_value, but _bfd_set_gp_value is currently an internal BFD function. That would need to change (give _bfd_set_gp_value a FUNCTION, SYNOPSIS, DESCRIPTION function comment, remove the declaration from libbfd-in.h, regenerate with --enable-maintainer-mode). > If so, that might be the easiest fix; simply provide a reasonable > value (e.g. address of the .toc section + 0x8000) in the symbol > table, and everything else ought to work out ... > > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU/Linux compilers and toolchain > Ulrich.Weigand@de.ibm.com -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-24 23:05 ` Alan Modra @ 2021-06-25 14:49 ` will schmidt 2021-07-09 16:51 ` will schmidt 1 sibling, 0 replies; 13+ messages in thread From: will schmidt @ 2021-06-25 14:49 UTC (permalink / raw) To: Alan Modra, Ulrich Weigand; +Cc: gdb-patches, rogerio, Carl E. Love On Fri, 2021-06-25 at 08:35 +0930, Alan Modra wrote: > On Thu, Jun 24, 2021 at 05:32:50PM +0200, Ulrich Weigand wrote: > > On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > > > > > I'm not at all familiar with gdb/compile, but it looks like > > > anything > > > to do with the GOT is unsupported. I can't see any handling for > > > GOT > > > relocs, for example. > > > > The basic approach seems to be: > > - Allocate memory in the inferior for each section > > - Use bfd_set_section_vma on all sections to provide the address > > - Load the symbol table via bfd_canonicalize_symtab > > - Modify the symbol table to provide values for all undefined > > symbols > > (via GDB looking them up in the rest of the inferior) > > - Use bfd_get_relocated_section_contents to load the contents of > > all sections, using the symbol table from above > > > > I think the assumption is that bfd_get_relocated_section_contents > > will handle any relocation type, including GOT/TOC relocs. > > > > > Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but > > > compile-object-load.c is just broken, I think. You can't set > > > .TOC. or > > > _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, > > > for > > > code that uses those symbols. > > > > Agreed, it looks like this makes the Intel-specific assumption that > > code uses PC-relative addressing for everything and does not > > actually > > rely on the value of _GLOBAL_OFFSET_TABLE_. I'm not sure this is > > even completely true for Intel, but it certainly isn't on Power. > > > > > > > Yes, we probably do need a proper value for .TOC. Usually, > > > > > this > > > > > is set by the linker to 0x8000 bytes after the beginning of > > > > > the .toc > > > > > section, I think. > > > > > > Again, I'm not familiar enough with the gdb compile support to > > > give > > > proper advice. If calls to functions in the newly > > > compiled/loaded > > > code is always via global entry points then you have some freedom > > > in > > > choosing your own .TOC. value. If direct calls to the local > > > entry > > > point are made then .TOC. should be set to the value used in > > > whatever > > > context is going to call the newly loaded object. That would be > > > tricky. > > > > Inferior calls should always use the global entry point, so that > > should be OK. I'm more concerned that we have to use the same > > value for .TOC. as will be used by > > bfd_get_relocated_section_contents > > for handling TOC-relative relocations. If we just define a value > > for the .TOC. symbol in the symbol table passed to > > bfd_get_relocated_section_contents, will this be used? > > No, just defining .TOC. won't be sufficient. A .TOC. symbol value > is used if the symbol is found in the linker hash table, but here we > aren't even invoking the linker. I think the gdb code should call > _bfd_set_gp_value, but _bfd_set_gp_value is currently an internal BFD > function. That would need to change (give _bfd_set_gp_value a > FUNCTION, SYNOPSIS, DESCRIPTION function comment, remove the > declaration from libbfd-in.h, regenerate with > --enable-maintainer-mode). Thanks (Both Uli and Alan) for the roadmap and the explanations and analysis here. :-) I'll work on this a bit and see where I end up. Thanks -Will > > > If so, that might be the easiest fix; simply provide a reasonable > > value (e.g. address of the .toc section + 0x8000) in the symbol > > table, and everything else ought to work out ... > > > > Bye, > > Ulrich > > > > -- > > Dr. Ulrich Weigand > > GNU/Linux compilers and toolchain > > Ulrich.Weigand@de.ibm.com > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-06-24 23:05 ` Alan Modra 2021-06-25 14:49 ` will schmidt @ 2021-07-09 16:51 ` will schmidt 2021-07-10 1:01 ` Alan Modra 1 sibling, 1 reply; 13+ messages in thread From: will schmidt @ 2021-07-09 16:51 UTC (permalink / raw) To: Alan Modra, Ulrich Weigand; +Cc: gdb-patches, rogerio, Carl E. Love On Fri, 2021-06-25 at 08:35 +0930, Alan Modra wrote: > On Thu, Jun 24, 2021 at 05:32:50PM +0200, Ulrich Weigand wrote: > > On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > > > > > I'm not at all familiar with gdb/compile, but it looks like > > > anything > > > to do with the GOT is unsupported. I can't see any handling for > > > GOT > > > relocs, for example. > > > > The basic approach seems to be: > > - Allocate memory in the inferior for each section > > - Use bfd_set_section_vma on all sections to provide the address > > - Load the symbol table via bfd_canonicalize_symtab > > - Modify the symbol table to provide values for all undefined > > symbols > > (via GDB looking them up in the rest of the inferior) > > - Use bfd_get_relocated_section_contents to load the contents of > > all sections, using the symbol table from above > > > > I think the assumption is that bfd_get_relocated_section_contents > > will handle any relocation type, including GOT/TOC relocs. > > > > > Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but > > > compile-object-load.c is just broken, I think. You can't set > > > .TOC. or > > > _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, > > > for > > > code that uses those symbols. > > > > Agreed, it looks like this makes the Intel-specific assumption that > > code uses PC-relative addressing for everything and does not > > actually > > rely on the value of _GLOBAL_OFFSET_TABLE_. I'm not sure this is > > even completely true for Intel, but it certainly isn't on Power. > > > > > > > Yes, we probably do need a proper value for .TOC. Usually, > > > > > this > > > > > is set by the linker to 0x8000 bytes after the beginning of > > > > > the .toc > > > > > section, I think. > > > > > > Again, I'm not familiar enough with the gdb compile support to > > > give > > > proper advice. If calls to functions in the newly > > > compiled/loaded > > > code is always via global entry points then you have some freedom > > > in > > > choosing your own .TOC. value. If direct calls to the local > > > entry > > > point are made then .TOC. should be set to the value used in > > > whatever > > > context is going to call the newly loaded object. That would be > > > tricky. > > > > Inferior calls should always use the global entry point, so that > > should be OK. I'm more concerned that we have to use the same > > value for .TOC. as will be used by > > bfd_get_relocated_section_contents > > for handling TOC-relative relocations. If we just define a value > > for the .TOC. symbol in the symbol table passed to > > bfd_get_relocated_section_contents, will this be used? > Hi, > No, just defining .TOC. won't be sufficient. A .TOC. symbol value > is used if the symbol is found in the linker hash table, but here we > aren't even invoking the linker. I think the gdb code should call > _bfd_set_gp_value, I've made some local changes so I'm now calling bfd_set_gp_value when the ".TOC." symbol is handled in compile_object_load. i.e. if (strcmp (sym->name, ".TOC.") == 0) bfd_set_gp_value(abfd.get(), sym->value); This is either wrong, or insufficient. :-) By plugging in different values in place of "sym->value" I can see that this affects a ld/lwa sequence later on, and I wonder if the offsets we are trying to load from are simply too large here. Some helpful(?) debug and recap,.. Our test is a "(gdb) compile print varint" per gdb/testsuite/compile/compile-print.exp. I've changed the varint value to 0x12345678 to server better as an eyecatcher. I've got a small number of local changes allowing us to at least find our compiler (patch attached for reference). When we enter _gdb_expr, r12 points to the function entry point, so in this case has the value 0x0000200000080000. >(gdb) disas >Dump of assembler code for function _gdb_expr: > 0x0000200000080000 <+0>: addis r2,r12,-8 > 0x0000200000080004 <+4>: addi r2,r2,0 > 0x0000200000080008 <+8>: std r31,-8(r1) > 0x000020000008000c <+12>: stdu r1,-80(r1) > 0x0000200000080010 <+16>: mr r31,r1 > 0x0000200000080014 <+20>: std r3,48(r31) > 0x0000200000080018 <+24>: std r4,56(r31) > 0x000020000008001c <+28>: addis r9,r2,0 <<--[1] > 0x0000200000080020 <+32>: ld r9,-32768(r9) <<--[2] > => 0x0000200000080024 <+36>: lwa r9,0(r9) <<--[3] > 0x0000200000080028 <+40>: stw r9,32(r31) > 0x000020000008002c <+44>: lwz r10,32(r31) > 0x0000200000080030 <+48>: ld r9,56(r31) > 0x0000200000080034 <+52>: stw r10,0(r9) > 0x0000200000080038 <+56>: nop > 0x000020000008003c <+60>: addi r1,r31,80 > 0x0000200000080040 <+64>: ld r31,-8(r1) > 0x0000200000080044 <+68>: blr > Passing in different values to bfd_set_gp_value in place of sym->value affects the offsets referenced at [1] and [2]. The value in r9 when we reach [3] is zero, so it SIGSEGVs on that. The familiar -32768 value at [2] suggests to me that we are trying to reach farther than allowed. (gdb) info reg r2 r2 0x200000000000 0x200000000000 (gdb) info reg r12 r12 0x200000080000 0x200000080000 (gdb) info address varint Symbol "varint" is static storage at address 0x100020010. (gdb) maint info section .data Exec file: `/home/willschm/gdb_builds/gdb-patches/a.out', file type elf64-powerpcle. [21] 0x100020000->0x100020038 at 0x00010000: .data ALLOC LOAD DATA HAS_CONTENTS (gdb) find 0x100020000,0x100020038,0x12345678 0x100020010 <varint> 1 pattern found. (gdb) find 0x200000000000,0x200000080000,0x12345678 Pattern not found. (gdb) find 0x200000080000,0x200000180000,0x12345678 Pattern not found. As another reference, this is what the disassembly looks like when we issue a "compile print main", which does not have any .TOC. references. (this works). > (gdb) disas > Dump of assembler code for function _gdb_expr: > 0x0000200000080000 <+0>: std r31,-8(r1) > 0x0000200000080004 <+4>: stdu r1,-80(r1) > 0x0000200000080008 <+8>: mr r31,r1 > 0x000020000008000c <+12>: std r3,48(r31) > 0x0000200000080010 <+16>: std r4,56(r31) > 0x0000200000080014 <+20>: lis r9,1 > 0x0000200000080018 <+24>: rldicr r9,r9,16,47 > 0x000020000008001c <+28>: ori r9,r9,2044 > 0x0000200000080020 <+32>: std r9,32(r31) > 0x0000200000080024 <+36>: ld r9,32(r31) > 0x0000200000080028 <+40>: lbz r10,0(r9) > 0x000020000008002c <+44>: ld r9,56(r31) > 0x0000200000080030 <+48>: stb r10,0(r9) > 0x0000200000080034 <+52>: nop > 0x0000200000080038 <+56>: addi r1,r31,80 > 0x000020000008003c <+60>: ld r31,-8(r1) > 0x0000200000080040 <+64>: blr > 0x0000200000080044 <+68>: .long 0x0 > 0x0000200000080048 <+72>: .long 0x0 > 0x000020000008004c <+76>: .long 0x1000180 > Help! :-) Thanks -Will Patches for reference, 1 - add target options. 2 - add/specify target triple. 3 - externalize bfd bfd_set_gp_value. 4 - call bfd_set_gp_value for .TOC. [Add target options] Add a ppc64_linux_gcc_target_options diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index a629450d746..5c2390f0e41 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -822,10 +822,18 @@ rs6000_stack_frame_destroyed_p (struct gdbarch *gdbarch, CORE_ADDR pc) { return rs6000_in_function_epilogue_frame_p (get_current_frame (), gdbarch, pc); } +/* Implement the linux_gcc_target_options method. */ +static std::string +ppc64_linux_gcc_target_options (struct gdbarch *gdbarch) +{ + return "-mcmodel=medium" ; +} + + /* Get the ith function argument for the current function. */ static CORE_ADDR rs6000_fetch_pointer_argument (struct frame_info *frame, int argi, struct type *type) { @@ -7127,10 +7135,13 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) /* Trampoline. */ set_gdbarch_in_solib_return_trampoline (gdbarch, rs6000_in_solib_return_trampoline); set_gdbarch_skip_trampoline_code (gdbarch, rs6000_skip_trampoline_code); + /* */ + set_gdbarch_gcc_target_options (gdbarch, ppc64_linux_gcc_target_options); + /* Hook in the DWARF CFI frame unwinder. */ dwarf2_append_unwinders (gdbarch); dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum); /* Frame handling. */ [Add target triplet] add a target triplet. (needs adjustment) diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c index 1e94922f25a..61a69a5de78 100644 --- a/gdb/ppc-linux-tdep.c +++ b/gdb/ppc-linux-tdep.c @@ -1971,10 +1971,17 @@ ppc_floatformat_for_type (struct gdbarch *gdbarch, } return default_floatformat_for_type (gdbarch, name, len); } +/* Specify the target triplet as appropriate.. */ +static const char * +ppc64le_gnu_triplet_regexp (struct gdbarch *gdbarch) +{ + return "powerpc64le?"; +} + static void ppc_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) { struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); @@ -2101,10 +2108,13 @@ ppc_linux_init_abi (struct gdbarch_info info, /* BFD target for core files. */ if (gdbarch_byte_order (gdbarch) == BFD_ENDIAN_LITTLE) set_gdbarch_gcore_bfd_target (gdbarch, "elf64-powerpcle"); else set_gdbarch_gcore_bfd_target (gdbarch, "elf64-powerpc"); + /* Set compiler triplet. */ + if (gdbarch_byte_order (gdbarch) == BFD_ENDIAN_LITTLE) + set_gdbarch_gnu_triplet_regexp (gdbarch, ppc64le_gnu_triplet_regexp); } set_gdbarch_core_read_description (gdbarch, ppc_linux_core_read_description); set_gdbarch_iterate_over_regset_sections (gdbarch, ppc_linux_iterate_over_regset_sections); [ eternalize bfd bfd_set_gp_value ] tweak bfd to externalize the bfd_set_gp_value function. diff --git a/bfd/bfd.c b/bfd/bfd.c index 6e5d3397d15..a53ad80190e 100644 --- a/bfd/bfd.c +++ b/bfd/bfd.c @@ -1849,10 +1849,28 @@ _bfd_set_gp_value (bfd *abfd, bfd_vma v) ecoff_data (abfd)->gp = v; else if (abfd->xvec->flavour == bfd_target_elf_flavour) elf_gp (abfd) = v; } +/* +FUNCTION + bfd_set_gp_value + +SYNOPSIS + void bfd_set_gp_value (bfd * abfd, bfd_vma v); + +DESCRIPTION + Allow external gdb to call this function for + gdb-compile support. +*/ + +void +bfd_set_gp_value (bfd *abfd, bfd_vma v) +{ + return _bfd_set_gp_value (abfd, v); +} + /* FUNCTION bfd_scan_vma SYNOPSIS [ call bfd_set_gp_value for .TOC. symbol ] diff --git a/gdb/compile/compile-object-load.c b/gdb/compile/compile-object-load.c index 1c512801bcd..56df153a89c 100644 --- a/gdb/compile/compile-object-load.c +++ b/gdb/compile/compile-object-load.c @@ -720,10 +720,27 @@ compile_object_load (const compile_file_names &file_names, need for _GLOBAL_OFFSET_TABLE_. Together with -fPIE the data remain PC-relative even with _GLOBAL_OFFSET_TABLE_ as zero. */ sym->value = 0; continue; } + if (strcmp (sym->name, ".TOC.") == 0) + { + fprintf_unfiltered (gdb_stdlog, + "ELF symbol \"%s\" found. calling bfd_set_gp_value %s\n", + sym->name, paddress (target_gdbarch (), sym->value)); + bfd_set_gp_value(abfd.get(), sym->value); + continue; + } + /* debug ... */ + if (strcmp (sym->name, "varint") == 0) + { + fprintf_unfiltered (gdb_stdlog, + "ELF symbol \"%s\" found. value is %s\n", + sym->name, paddress (target_gdbarch (), sym->value)); + continue; + } + bmsym = lookup_minimal_symbol (sym->name, NULL, NULL); switch (bmsym.minsym == NULL ? mst_unknown : MSYMBOL_TYPE (bmsym.minsym)) { case mst_text: > but _bfd_set_gp_value is currently an internal BFD > function. That would need to change (give _bfd_set_gp_value a > FUNCTION, SYNOPSIS, DESCRIPTION function comment, remove the > declaration from libbfd-in.h, regenerate with > --enable-maintainer-mode). > > > If so, that might be the easiest fix; simply provide a reasonable > > value (e.g. address of the .toc section + 0x8000) in the symbol > > table, and everything else ought to work out ... > > > > Bye, > > Ulrich > > > > -- > > Dr. Ulrich Weigand > > GNU/Linux compilers and toolchain > > Ulrich.Weigand@de.ibm.com > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-07-09 16:51 ` will schmidt @ 2021-07-10 1:01 ` Alan Modra 2021-07-13 4:33 ` will schmidt 0 siblings, 1 reply; 13+ messages in thread From: Alan Modra @ 2021-07-10 1:01 UTC (permalink / raw) To: will schmidt; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote: > I've made some local changes so I'm now calling bfd_set_gp_value when > the ".TOC." symbol is handled in compile_object_load. > i.e. > if (strcmp (sym->name, ".TOC.") == 0) > bfd_set_gp_value(abfd.get(), sym->value); > > This is either wrong, or insufficient. :-) Symbol value here is section relative. You need to add the symbol section vma, which is set by setup_sections_data::setup_one_section. If that doesn't help, I would run gdb under gdb with a breakpoint on ppc64_elf_toc_reloc looking to see whether that function is using the value you expect given your bfd_set_gp_value call. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-07-10 1:01 ` Alan Modra @ 2021-07-13 4:33 ` will schmidt 2021-07-13 11:11 ` Alan Modra 0 siblings, 1 reply; 13+ messages in thread From: will schmidt @ 2021-07-13 4:33 UTC (permalink / raw) To: Alan Modra; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote: > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote: > > I've made some local changes so I'm now calling bfd_set_gp_value > > when > > the ".TOC." symbol is handled in compile_object_load. > > i.e. > > if (strcmp (sym->name, ".TOC.") == 0) > > bfd_set_gp_value(abfd.get(), sym->value); > > > > This is either wrong, or insufficient. :-) > > Symbol value here is section relative. You need to add the symbol > section vma, which is set by setup_sections_data::setup_one_section. So is that creating a new section named vma, or updating one of the existing sections? I see that we currently call setup_one_section for all(?) of the sections , the full list being .data, .bss, .toc, .debug_info, .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment, .note.GNU-stack, .debug_frame. It appears we call bfd_set_section_vma (sect, m_last_size); for each of those. I can't immediately tell if or how I should try adding a call to bfd_set_gp_value from within there. (how to get to the parent abfd from within a scope that only deals with the section?) If/when I sort that part out, I'm still not sure what value I should be trying to set that gp value to. :-) > > If that doesn't help, I would run gdb under gdb with a breakpoint on > ppc64_elf_toc_reloc looking to see whether that function is using the > value you expect given your bfd_set_gp_value call. At the moment (before further changes).. (gdbouter) p TOCstart $42 = 01000000002200000 Thanks -Will ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-07-13 4:33 ` will schmidt @ 2021-07-13 11:11 ` Alan Modra 2021-07-13 22:59 ` will schmidt 0 siblings, 1 reply; 13+ messages in thread From: Alan Modra @ 2021-07-13 11:11 UTC (permalink / raw) To: will schmidt; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Mon, Jul 12, 2021 at 11:33:05PM -0500, will schmidt wrote: > On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote: > > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote: > > > I've made some local changes so I'm now calling bfd_set_gp_value > > > when > > > the ".TOC." symbol is handled in compile_object_load. > > > i.e. > > > if (strcmp (sym->name, ".TOC.") == 0) > > > bfd_set_gp_value(abfd.get(), sym->value); > > > > > > This is either wrong, or insufficient. :-) > > > > Symbol value here is section relative. You need to add the symbol > > section vma, which is set by setup_sections_data::setup_one_section. > > > So is that creating a new section named vma, or updating one of the > existing sections? sym is of type asymbol*, one of the fields of asymbol is "section". I was referring to sym->section->vma when I wrote the above, but on thinking about it some more, I see that won't be correct. We aren't performing a final link here, just loading up object files and trying to stitch them together. So I think you'll find that the .TOC. sym->section is bfd_und_section_ptr. You'll need to do as the linker would, set both the .TOC symbol value and section, then pass the sym->value + sym->section->vma - 0x8000 to bfd_set_gp_value. (Somewhat oddly, the ppc64 bfd code defines a gp_value offset by 0x8000, ie. what would normally be the start of the TOC given an initial toc pointer or .TOC. at 0x8000 into that section.) Something like if (strcmp (sym->name, ".TOC.") == 0) { asection *toc = bfd_get_section_by_name (abfd.get(), ".toc"); sym->section = toc; sym->value = 0x8000; bfd_set_gp_value (abfd.get(), toc); } What to do on not finding a .toc section I'll leave as an exercise. > I see that we currently call setup_one_section for all(?) of the > sections , the full list being .data, .bss, .toc, .debug_info, > .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment, > .note.GNU-stack, .debug_frame. > It appears we call bfd_set_section_vma (sect, m_last_size); for each > of those. > I can't immediately tell if or how I should try adding a call to > bfd_set_gp_value from within there. (how to get to the parent abfd > from within a scope that only deals with the section?) section->owner gives the parent bfd, but it is probably tidier to leave calling bfd_set_gp_value to when you find you have a .TOC. symbol. The point being that the only reason you have to do anything about the gp_value is to force the value used in relocations against the .TOC. symbol to agree with the value used by all the R_PPC64_TOC* relocations. > If/when I sort that part out, I'm still not sure what value I should be > trying to set that gp value to. :-) > > > > > If that doesn't help, I would run gdb under gdb with a breakpoint on > > ppc64_elf_toc_reloc looking to see whether that function is using the > > value you expect given your bfd_set_gp_value call. > > At the moment (before further changes).. > > > (gdbouter) p TOCstart > $42 = 01000000002200000 > > > Thanks > -Will -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." 2021-07-13 11:11 ` Alan Modra @ 2021-07-13 22:59 ` will schmidt 0 siblings, 0 replies; 13+ messages in thread From: will schmidt @ 2021-07-13 22:59 UTC (permalink / raw) To: Alan Modra; +Cc: Ulrich Weigand, gdb-patches, rogerio, Carl E. Love On Tue, 2021-07-13 at 20:41 +0930, Alan Modra wrote: > On Mon, Jul 12, 2021 at 11:33:05PM -0500, will schmidt wrote: > > On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote: > > > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote: > > > > I've made some local changes so I'm now calling > > > > bfd_set_gp_value > > > > when > > > > the ".TOC." symbol is handled in compile_object_load. > > > > i.e. > > > > if (strcmp (sym->name, ".TOC.") == 0) > > > > bfd_set_gp_value(abfd.get(), sym->value); > > > > > > > > This is either wrong, or insufficient. :-) > > > > > > Symbol value here is section relative. You need to add the > > > symbol > > > section vma, which is set by > > > setup_sections_data::setup_one_section. > > > > > > So is that creating a new section named vma, or updating one of the > > existing sections? > > sym is of type asymbol*, one of the fields of asymbol is > "section". I > was referring to sym->section->vma when I wrote the above, but on > thinking about it some more, I see that won't be correct. We aren't > performing a final link here, just loading up object files and trying > to stitch them together. So I think you'll find that the > .TOC. sym->section is bfd_und_section_ptr. You'll need to do as the > linker would, set both the .TOC symbol value and section, then pass > the sym->value + sym->section->vma - 0x8000 to bfd_set_gp_value. > (Somewhat oddly, the ppc64 bfd code defines a gp_value offset by > 0x8000, ie. what would normally be the start of the TOC given an > initial toc pointer or .TOC. at 0x8000 into that section.) Thanks! :-) > Something like > > if (strcmp (sym->name, ".TOC.") == 0) > { > asection *toc = bfd_get_section_by_name (abfd.get(), ".toc"); > sym->section = toc; > sym->value = 0x8000; > bfd_set_gp_value (abfd.get(), toc); That last line changed to this seems to work: bfd_set_gp_value(abfd.get(), sym->value + sym->section->vma - 0x8000); Which is as you described it in the paragraph above. :-) At this time the gdb.compile set of tests looks much better.. > make check RUNTESTFLAGS="gdb.compile/compile-*.exp" > ... > === gdb Summary === > > # of expected passes 97 > # of unexpected failures 39 > # of known failures 17 > # of unresolved testcases 6 I have several weeks worth of debug/hack code in place now, fingers crossed a bunch of those failures clear up once I get my debug junk out of the way. I'll post a clean set of patches when they are ready,.. Thanks -WIll > } > > What to do on not finding a .toc section I'll leave as an exercise. > > > I see that we currently call setup_one_section for all(?) of the > > sections , the full list being .data, .bss, .toc, .debug_info, > > .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment, > > .note.GNU-stack, .debug_frame. > > It appears we call bfd_set_section_vma (sect, m_last_size); for > > each > > of those. > > I can't immediately tell if or how I should try adding a call to > > bfd_set_gp_value from within there. (how to get to the parent > > abfd > > from within a scope that only deals with the section?) > > section->owner gives the parent bfd, but it is probably tidier to > leave calling bfd_set_gp_value to when you find you have a > .TOC. symbol. The point being that the only reason you have to do > anything about the gp_value is to force the value used in relocations > against the .TOC. symbol to agree with the value used by all the > R_PPC64_TOC* relocations. > > > If/when I sort that part out, I'm still not sure what value I > > should be > > trying to set that gp value to. :-) > > > > > > > > If that doesn't help, I would run gdb under gdb with a breakpoint > > > on > > > ppc64_elf_toc_reloc looking to see whether that function is using > > > the > > > value you expect given your bfd_set_gp_value call. > > > > At the moment (before further changes).. > > > > > > (gdbouter) p TOCstart > > $42 = 01000000002200000 > > > > > > Thanks > > -Will > > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-07-13 22:59 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-22 18:54 gdb compile for powerpc64 target - Could not find symbol ".TOC." will schmidt 2021-06-23 15:36 ` Ulrich Weigand 2021-06-23 17:37 ` will schmidt 2021-06-24 3:11 ` Alan Modra 2021-06-24 4:39 ` Alan Modra 2021-06-24 15:32 ` Ulrich Weigand 2021-06-24 23:05 ` Alan Modra 2021-06-25 14:49 ` will schmidt 2021-07-09 16:51 ` will schmidt 2021-07-10 1:01 ` Alan Modra 2021-07-13 4:33 ` will schmidt 2021-07-13 11:11 ` Alan Modra 2021-07-13 22:59 ` will schmidt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).