On 26 May 2015 at 17:35, Guillem Jover <[email protected]> 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.
Well, as I far as I understand the binutils code (not especially far), this hasn't changed since 1999. I got the number of spaces from this line: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=ab010d46f4b76d7da9985adef366f4be62c561a4;hb=252b5132c753830d5fd56823373aed85f2a0db63#l811 (There is older history in the binutils git but it seems that master does not have the older stuff in its history and it confuses me) > 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
