Hi Steve!
I was recently working on the Dpkg::Shlibs::Objdump module code
related to ELF and ABI tracking, and when seeing the ARM handling
missing there, recalled the issues we saw some time ago with ARM
when I tried to make that tracking more strict, which had to be
reverted due to issues with objects in the wild. For context that
was #853793.
I was wondering whether you (or know if someone else) had worked on
the ARM port side of things to clean up those issues, from toolchain to >specific objects in packages? I'm not in a hurry to add that code back
so do not feel any pressure from this, I'm mostly wondering where we are
at with this, and whether there is something I can improve from dpkg side
in that regard, but if not that's also fine, and then I'd probably try
to update the status somewhere (code comment or wiki or something).
(I think at least the issue with wine should be solved now with commit >https://salsa.debian.org/wine-team/wine/-/commit/51f48d3e6c04cef760610d14ba5f368e7f2baf7a)
If we're still seeing
issues in packages today, then maybe we might find some help from
Wookey or Emmanuel (who should both be reading this list!).
On 2023-05-03 21:50 +0100, Steve McIntyre wrote:
If we're still seeing
issues in packages today, then maybe we might find some help from
Wookey or Emmanuel (who should both be reading this list!).
I am, and have noticed this issue and put it on our list of things to look at. I was going to wait until I had something useful to say before
replying :-)
I was recently working on the Dpkg::Shlibs::Objdump module code
related to ELF and ABI tracking, and when seeing the ARM handling
missing there, recalled the issues we saw some time ago with ARM
when I tried to make that tracking more strict, which had to be
reverted due to issues with objects in the wild. For context that
was #853793.
On 2023-04-27 11:27, Guillem Jover wrote:
I was recently working on the Dpkg::Shlibs::Objdump module code
related to ELF and ABI tracking, and when seeing the ARM handling
missing there, recalled the issues we saw some time ago with ARM
when I tried to make that tracking more strict, which had to be
reverted due to issues with objects in the wild. For context that
was #853793.
My understanding is that the problematic cases are ELF files with:
(1) EABIv4 instead of EABIv5
(2) armhf files with the ARM_SOFT_FLOAT flag set
(3) armel files with the ARM_HARD_FLOAT flag set
Is that correct? Anything else?
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. And rechecking the commit message, it seems there were also
objects with both ABI float flags set at the same time.
I'm not sure whether you plan on analyzing all ELF objects in the
Debian archive for the Arm architectures, but if so, that would be
rather helpful. But thanks in any case for looking into this!
I'll look at the soft/hard float ones next.
On 2023-06-16 11:19, Emanuele Rocca wrote:...
(1) I couldn't find any armel object with the hard-float flag set.
(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, 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.
Full list of armhf packages shipping ELF objects with the soft-float...
flag set:
u-boot-rockchip
u-boot-rpi
u-boot-sunxi
u-boot-tegra
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.
And rechecking the commit message, it seems there were also
objects with both ABI float flags set at the same time.
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.
You mentioned in #853793 paris-traceroute also targeting Version4, but
that package is now gone.
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.
(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,
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.
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
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
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
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.
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?
On Fri, 2023-06-16 at 11:19:21 +0200, Emanuele Rocca wrote:
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? :)
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.
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
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
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 56:21:32 |
Calls: | 6,712 |
Files: | 12,243 |
Messages: | 5,355,475 |