Hi,
It has been more than 3 months since 0.163 and I would like to push out
a new release end of the week. There have been more than 45 commits and
various bugs fixed. Some of which have already been backported to some
distros. Lets try to get any pending patches in on Wednesday and do a
release on Friday after some extra testing. Don't worry if any patches
don't make it for this release. We will do another release in ~3 months
again.
I don't intent to do a "portable patch" for this release. If you did use
the portable patch for 0.163 please post your setup and any patches you
depend on so we can include them in the regular release if possible.
Thanks,
Mark
Show replies by date
Testing looks good. I did find one small issue with the dwfl_proc_attach
testcase if there is no libelf.so installed yet on the host. Josh helped
me analyze and we believe the correct fix is to make sure the AM_LDFLAGS
are always included. So tests/Makefile.am gets:
- dwfl_proc_attach_LDFLAGS = -pthread
+ dwfl_proc_attach_LDFLAGS = -pthread $(AM_LDFLAGS)
With that I get zero FAIL on Debian i686 and x86_64, Fedora x86_64, i686,
arm, aarch64, s390, s390x, ppc64 and ppc64le and various RHEL6 and RHEL7
arches.
But I see one FAIL on ppc32. This is caused by the fact that we now do
more eu-elflint checks for the eu-strip/eu-unstrip roundtripping. There
are two issues:
- ppc_check_special_symbol contains a special case for the small data
area base symbol _SDA_BASE_. It does need to be associated with the
.sdata section and at an offset of sh_addr + 0x8000. But it seems
that sometimes there might not be an small data area section because
there is just very little or no data. In which case _SDA_BASE_ is
associated with the .data section and has a different offset. I intent
to just change the special case to:
return (((strcmp (sname, ".sdata") == 0
&& sym->st_value == destshdr->sh_addr + 0x8000)
|| strcmp (sname, ".data") == 0)
&& sym->st_size == 0);
which might be a little too loose, but I don't see a good/better way
to check the _SDA_BASE_ symbol value and this is a very special ppc32
only corner case.
- elflint doesn't like it when relocations are applied to a mergeable
section. But ppc32 does seem to have such relocations. And gabi seems
to allow it ("Relocations referencing elements of such sections must be
resolved to the merged locations of the referenced values"). I think
this can work if the elements are actually of the same size. It seems
what we really want to prevent is relocations against sections
containing mergeable strings, which are of arbitrary size. So I intent
to change that check to:
@@ -1254,9 +1254,10 @@ section [%2d] '%s': sh_info should be zero\n"),
}
}
- if (((*destshdrp)->sh_flags & (SHF_MERGE | SHF_STRINGS)) != 0)
+ if ((((*destshdrp)->sh_flags & SHF_MERGE) != 0)
+ && ((*destshdrp)->sh_flags & SHF_STRINGS) != 0)
ERROR (gettext ("\
-section [%2d] '%s': no relocations for merge-able sections possible\n"),
+section [%2d] '%s': no relocations for merge-able string sections
possible\n"),
idx, section_name (ebl, idx));
}
}
Sorry for not posting proper patches for these issue, it is a bit late here.
I'll create proper patches tomorrow before the release. Unless people object
to the above tweaks to make ppc32 zero FAIL too.
Cheers,
Mark