Sorry for the truncated reply. On 26 May 2015 at 17:35, Guillem Jover <guil...@debian.org> 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 <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.
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;hb=dab394de9e41de54df5e2310e081e1c550326f5b#l1582 and it was there in the initial import: 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 ancestry 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. You can tell I'm not a perl natural because I replaced a regexp with some logic :-) > But I'm still > uncertain if it is a good idea, given that it has the potential to > break existing stuff. Well yeah, that's the fear. It would be possible to do something only in the case of a Go shared library, but that sounds pretty horrible. > It would be nice if the unit test would cover versions longer than > the normal space padding, and the visibility attributes. I'll try to do that tomorrow. >> > 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? I can't really see how you could have that happen without determined effort. The user is expected to use the go tool to create and link to the shared libraries, and that uses different directory for "gc stuff" and "gccgo stuff" (and the stuff includes the .so symlinks). >> > - 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? Being able to distribute security fixes to a library by just updating the library not all its rdeps and also size on disk; something I did earlier today: mwhudson@glamdring:golang$ go build debian/readabihash.go mwhudson@glamdring:golang$ ls -lh readabihash -rwxrwxr-x 1 mwhudson mwhudson 3.1M May 26 10:03 readabihash mwhudson@glamdring:golang$ go build -linkshared debian/readabihash.go mwhudson@glamdring:golang$ ls -lh readabihash -rwxrwxr-x 1 mwhudson mwhudson 26K May 26 10:03 readabihash (and we want to write Go stuff for the phone...) > 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. Yes. I was told by people who know more about this than I do that this would be painful but not disastrously so. > 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? I don't understand. It remains to be seen but I suspect that most new upstream releases of Go things will break ABI and only targeted bugfixes will not. We'll see how things play out in practice. And in the long term (say 5 years or so), I expect the toolchain will settle down a bit. >> > - How would this handle interop with languages that do not suppor >> > 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? I don't. >> >> 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)? Well the end of the discussion was that I would try to fix the perl. If I fail, I guess I'll go back to upstream... > 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. Well, C++ has other reasons for needing mangling of course. Cheers, mwh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
