Re: RFH: nsd on mips

[Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>]

Ben Burton wrote:
> 
> Hi.
> 
> > nsd doesn't have it's own xfer program, so it uses bind as build depends
> > and copies named-xfer to nsd-xfer on build time.  On mips (and only on
> > mips) it breaks

I'm pretty sure it will break on mipsel the same way.

> > when dependencies are tried (ldd nsd-xfer).  Could
> > someone please look at this issue and try to build it manualy?
> 
> I've taken a look at this -- the build fails in my mips/unstable chroot
> also.
> 
> The problem is at the dh_strip stage.  Your package takes the
> (already-stripped) named-xfer from bind and runs dh_strip, which strips
> it again.  It is after this that the executable becomes broken.
> 
> Some further testing shows that on my main sarge system (binutils
> 2.14.90.0.7-8), running strip on the original named-xfer does nothing to
> the executable (as expected, since it was already stripped during the
> bind build).  In my sid chroot (binutils 2.15-1), running strip on the
> original named-xfer results in a further reduction in size and a broken
> executable.

Between 2.14 and 2.15 the alignment of loadable ELF segments changed
from 0x1000 to 0x10000. This allows to support larger (and more
efficient) page sizes in future. So 2.14 and 2.15 are internally
consistent in their assumptions about the object file layout, but if
you use strip from 2.15 on a executable created with 2.14, strip can't
fulfil the alignment requirement it knows about and switches to the
default section alignment of 0x10. The readelf -l output shows this
effect clearly:

File: /usr/sbin/named-xfer
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00400000 0x00400000 0x5ed60 0x5ed60 R E 0x1000
  LOAD           0x05f000 0x10000000 0x10000000 0x01ca8 0x05128 RW  0x1000

File: debian/nsd/usr/sbin/nsd-xfer
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00400000 0x00400000 0x5ed60 0x5ed60 R E 0x10
  LOAD           0x05ed60 0x10000000 0x10000000 0x01ca8 0x05128 RW  0x10

I don't know if this incompatibility qualifies as a binutils bug.

[snip]
> I'm not sure precisely what's breaking, but as a temporary workaround
> you could simply exclude nsd-xfer from dh_strip (e.g., pass a -X
> argument to dh_strip, but I don't know what the cdbs mechanism is for
> doing this).  Strictly speaking this should be fine since named-xfer
> should be stripped anyway according to policy.

I think this is preferable regardless of strip's behaviour. There's no
point in stripping an executable several times.


Thiemo