On 20 May 2015 at 09:24, Guillem Jover <guil...@debian.org> wrote: > Hi! > > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote: >> Package: libdpkg-perl >> Version: 1.17.25ubuntu1 >> Severity: normal >> >> I have been working on adding support to the native Go toolchain for shared >> libraries. > > Cool! I've long considered languages not supporting shared libraries > to not be very compelling (to put it mildly :).
:-) >> Upstream git now produces shared libraries and dpkg-shlibdeps >> complains noisily when processing them: >> >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: >> 00000000002884d8 R_X86_64_64 >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000088 >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: >> 00000000002884f0 R_X86_64_64 >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0000000000000090 >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: >> 0000000000288858 R_X86_64_64 >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string >> dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: >> 0000000000288940 R_X86_64_64 >> type.func(*launchpad.net/go-xdg/v0.XDGDir) []string >> >> I suppose a few regexp tweaks are required. > > This would imply changing the regexes to match on column basis or very > strict amount of spaces, because there are valid cases where a version > node or the visibility markers might or not be present, which seems a > bit more flaky, although I doubt the objdump output format has changed > for a long time, but we'd have to verify that. Yeah, the patch I wrote yesterday (at http://paste.ubuntu.com/11232233/) checks for the number of spaces indicated by an absent version. A bit fragile but I don't suppose this is very likely to change. Parsing the ELF would be better but obviously a bunch of work (Go has a nice ELF library :-), doesn't support versions though). > In any case, there's several things that come to mind why on first > thought this might seem like not an entirely good idea anyway (w/o > having never actually looked deep into Go in any serious way): > > - Is the ABI (for each supported arch) specified as part of the > language, or is it an implementation detail? Oh very much an implementation detail at this point. > + If the latter, it means this might allow linking incompatible > objects, which is one of the reasons C++ does not specify the > mangling rules. > - Do the symbol names interop with GCC Go? I don't know for sure about the names, but there is no chance of the native toolchain and gccgo directly interoperating anyway: the native toolchain does not follow the platform ABI. > - How would this handle ABI changes in the future if the symbols are > not mangled? At least in the medium term, there is not going to be anywhere near as much ABI stability over time with a Go library compared to a C or even C++ library. A new compiler version implies a new ABI version, for example. > - How would this handle interop with languages that do not support > spaces? Can you specify to export to a specific language so that > it gets symbols mangled for that? Or do you need something else > like manually specifying the symbols in asm, or something like > FFI? Go and other code can not interoperate directly (see above comments about not following ABI). There is a thing (cgo) that generates code to support thunking between the two worlds, and you can make it generate symbols that conform to C's expectations. Besides that, the symbols that end up containing spaces are not the sort of things that other languages want to access, it's mostly stuff like the data for a type. > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote: >> Package: libdpkg-perl >> Version: 1.17.25 >> Followup-For: Bug #785344 >> >> It seems that ELF symbol names can contain any characters, except "\0". >> So a correct solution would be read ELF from perl, instead of using the >> output of objdump. (Unless objdump has a -0 option similar to xargs...) > > While it's true that those are allowed symbols, as I could not find > anything stating otherwise in the ELF spec, I've to wonder about the > wisdom of that choice? But when handling dpkg issues, my most > conservative side comes afloat, so it might just be that talking here. :) > > And Implementing an ELF parser in perl, just to be able to support Go, > does not seem very compelling, no. > >> This discussion at golang provides some background: >> https://go-review.googlesource.com/19101 > > It complains about a session expired and that I need to login, after > ignoring the dialog, I cannot see anything there. I think he means https://go-review.googlesource.com/#/c/10191/ Cheers, mwh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
