[PATCH] configury : Fix LEB128 support for non-GNU assemblers.
Thu Nov 26 20:28:13 GMT 2020
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>> On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote:
>>> which shows that the problem is detected in the depths of
>>> libbacktrace's DWARF reader. There's something completely off in
>>> places, like line numbers well beyond the end of dwarf.c.
>>> TBH, I don't really feel like diving into the innards of libbacktrace
>>> and DWARF at this point to investigate.
>> Perhaps try binutils readelf -wi or dwarflint etc. to find out where
>> go wrong, and then just look at the assembly and whether it matches what
>> made out of it?
> that was certainly easier than getting into libbacktrace. I've looked
> for the smallest object linked into libgo that showed readelf -wi
> differences. errors.o had
> No wonder things go astray from there…
maybe this is enough to cover all bases without having to do any version or
target checks. (untested)
objdump is not available on quite a few Darwin versions with perfectly
uleb128 - so I don’t want to punt on those for absence of it. We already
# Check if we have .[us]leb128, and support symbol arithmetic with it.
# Older versions of GAS and some tools based on those, have a bugs handling
# these directive, even when they appear to accept them.
gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128,
.uleb128 L2 - L1
if test "x$gcc_cv_objdump" != x; then
if $gcc_cv_objdump --full-contents conftest.o 2>/dev/null \
| grep '04800a8e 78808080 80808080 808001' >/dev/null; then
elif test "x$gcc_cv_otool" != x; then
if $gcc_cv_otool -d conftest.o 2>/dev/null \
| grep '04 80 0a 8e 78 80 80 80 80 80 80 80 80 80 01' >/dev/null; then
# play safe, assume the assembler is broken.
[Define if your assembler supports .sleb128 and .uleb128.])],
[Define if your assembler supports .sleb128 and .uleb128.])])
More information about the Gcc-patches