Hi! On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote: > On 20 May 2015 at 09:24, Guillem Jover <guil...@debian.org> wrote: > > On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote: > >> Package: libdpkg-perl > >> Version: 1.17.25ubuntu1 > >> Severity: normal
> >> 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). As mentioned above, we'd need to check if this has changed in the past, and if so how long ago. W/o having checked deeply, I think the patch can be simplified, by just changing the regex to cover the different cases. But I'm still uncertain if it is a good idea, given that it has the potential to break existing stuff. It would be nice if the unit test would cover versions longer than the normal space padding, and the visibility attributes. > > 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. Ok. > > + 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. But if the symbols match then users might end up linking both, which might become run-time errors instead of link-time ones? This would not seem ideal. Or is there something else to guarantee no mixups? > > - 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. Hmm, so what would be the point of shared libraries then? If a new compiler version implies a new ABI version, then that will require rebuilding the world, with flag-day transitions, and automatic SOVERSION bumps or Conflicts or similar. I'm also not seeing how it could provide a stable ABI w/o some kind of mangling, or at lest some ABI namespaceing or tagging? > > - 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. Right, I realized that after sending my reply, when I actually peeked at the spec for what were valid identifiers. :) > > On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote: > >> 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. I didn't find any perl module in CPAN exposing everything that we'd need to be able to switch to. Do you know of any? > >> 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/ Ah thanks. So, there seems to be some comments about mangling at least spaces (or did I misinterpret that)? Andwhile I could agree that the dpkg perl modules are "buggy" because they do not support spaces, as allowed by the ELF specs. It seems the C++ approach was pretty wise when choosing to mangle the symbols and sidestepped any such issue entirely. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
