Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches
Hi!
On Fri, 2023-06-16 at 11:19:21 +0200, Emanuele Rocca wrote:
> I did a first pass, and it seems that the only objects with Version4 are
> generated by tcc.
>
> Flags according to readelf -h on armel:
> 0x4000200, Version4 EABI, <unknown>
>
> And on armhf:
> 0x4000400, Version4 EABI, <unknown>
>
> For reference, the files are:
>
> /usr/lib/arm-linux-gnueabi{,hf}/tcc/bcheck.o
> /usr/lib/arm-linux-gnueabi{,hf}/tcc/bt-exe.o
> /usr/lib/arm-linux-gnueabi{,hf}/tcc/bt-log.o
>
> Those are probably not particularly interesting for dpkg-shlibdeps, but
> I've filed #1038162 nonetheless.
Thanks, and right I guess as long as no package builds using tcc and
we do not end up with those in the archive, then that seems fine. But
in any case it would indeed be nice to get fixed.
> You mentioned in #853793 paris-traceroute also targeting Version4, but
> that package is now gone.
Ah, good then, I guess. :)
On Wed, 2023-06-21 at 15:22:11 +0200, Emanuele Rocca wrote:
> On 2023-06-16 11:19, Emanuele Rocca wrote:
> > I'll look at the soft/hard float ones next.
>
> Two findings.
>
> (1) I couldn't find any armel object with the hard-float flag set.
Great!
> (2) There are a few armhf packages shipping files with the soft-float flag.
>
> All of them, with the exception of the u-boot packages,
I agree with Vagrant, that this does not seem problematic, and I guess
strictly speaking boot loaders would instead be packaged as part of
some kernel-less architecture, but because we are not there now (or
ever), then this seems fine.
> are written in
> Pascal. It seems that fpc just emits the wrong flags. As an example,
> here is the readelf output for the armhf version of cqrlog. Note that
> Tag_ABI_VFP_args is not set either.
Oh, hmm, could you file a report for this (perhaps preferably
upstream)? (Or perhaps you did already? :)
> Full list of armhf packages shipping ELF objects with the soft-float
> flag set:
>
> astap
> astap-cli
> c-evo-dh-gtk2
> c-evo-dh-stdai
> cqrlog
> doublecmd-gtk
> doublecmd-plugins
> doublecmd-qt
> el-ixir
> fp-compiler-3.2.2
> fp-ide-3.2.2
> fp-units-castle-game-engine
> fp-units-rtl-3.2.2
> fp-utils-3.2.2
> gearhead
> gearhead-sdl
> goverlay
> lazpaint-gtk2
> lazpaint-qt5
> mricron
> nbc
> pasdoc
> tomboy-ng
[…]
> view3dscene
> winff-gtk2
> winff-qt
Hmm I guess these are going to be problematic for dpkg-shlibdeps when
trying to analyze these objects against the shared libraries they link
against.
On Tue, 2023-06-27 at 15:16:22 +0200, Emanuele Rocca wrote:
> On 2023-06-15 11:21, Guillem Jover wrote:
> > AFAIR there was also the case of objects being annotated with
> > Tag_ABI_VFP_args but not with either of the ABI hard or soft float
> > flags.
>
> Indeed, there are 1 armel and 91 armhf binary packages shipping ELF
> files without float flags (hard or soft) but with TAG_ABI_VFP_ARGS.
>
> Examples:
>
> gcc-arm-none-eabi_12.2.rel1-1_armel.deb ./usr/lib/gcc/arm-none-eabi/12.2.1/arm/v5te/hard/crtbegin.o 0x5000000: Version5 EABI TAG_ABI_VFP_ARGS
Given that this looks like a cross toolchain, it might need to be
exempted, as these might end up shipping objects for the target arch
which will not match the package arch.
> clisp-module-fastcgi_2.49.20210628.gitde01f0f-3_armhf.deb ./usr/lib/clisp-2.49.93+/fastcgi/fastcgi.o 0x5000000: Version5 EABI TAG_ABI_VFP_ARGS
This seems like something to fix.
> What do we want to do about those? I can take care of filing bug reports
> asking to add the missing flags if we agree it's a good idea.
I guess it would be interesting to know whether this is due to these
having been built with old toolchains (and never been rebuilt since),
or there's some toolchain or build machinery issue at play or similar.
Otherwise it would be nice to get consistency here, and I'm in
particular looking forward to being able to re-enable the ABI checker
in dpkg-shlibdeps. :)
> > And rechecking the commit message, it seems there were also
> > objects with both ABI float flags set at the same time.
>
> I couldn't find any such case in my analysis, do you perhaps remember
> which objects were affected?
Rechecking the bug report, it looks like this was the part with
sonames2elf from wine, which is supposedly fixed now. But it seems
there was a potential problem with gcc mishandling builds that did not
include libc, see this message which describes this a bit more:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853793#45
where I don't know whether that part got reported or is fixed in gcc.
And thanks for doing this analysis! Much appreciated.
Regards,
Guillem
Reply to: