Hello, On Tue, May 26, 2015 at 07:35:22AM +0200, Guillem Jover wrote: > Hi! > > On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote: > > On 20 May 2015 at 09:24, Guillem Jover <[email protected]> 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?
No, I don't know either. Those available on CPAN are roughly wrappers of readelf or something else, probably not better than our wrapper of objdump. I'm trying to write a XS module for libbfd, but that won't be anything close to stable and ready to use. > > > >> 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. Sorry for the glitch in the url. I've also seen this complaint after I opened it the second time... > > > > 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 Regards, Yixuan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
