diff mbox series

configury : Fix LEB128 support for non-GNU assemblers.

Message ID 0099CE62-D849-40BA-BCBD-1AD3882AA9AD@sandoe.co.uk
State New
Headers show
Series configury : Fix LEB128 support for non-GNU assemblers. | expand

Commit Message

Iain Sandoe Nov. 25, 2020, 9:49 a.m. UTC 
Hi,

I’ve had this patch in my Darwin trees for (literally) years, it is  
relevant to
the GCC ports that use a non-binutils assembler.

At present, even if such an assembler supports LEB128,  the GCC config
is setting HAVE_LEB128 = 0.

The ports I know of that can benefit from a change here are:

AIX (unaffected by this change, since the assembler [at least on gcc119] does
         not support leb128 directives)

Darwin (checked the various different assemblers)

GCN (I can’t test this, so Andrew, please could you say if the change
           is OK for that)

Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would
             want wider checks).

I guess we could exclude specific ports that don’t want to use leb128 with
a target elif in the configuration.

OK for master?

thanks
Iain

===== commit message

Some assemblers that either do not respond to --version, or are non-GNU,
do support leb128 directives.  The current configuration test omits these
cases and only supports GNU assemblers with a version > 2.11.

The patch extends the asm test to cover one failure case present in
assemblers based off an older version of GAS (where a 64 bit value with
the MSB set presented to a .uleb128 directive causes a fail).

This change then assumes that a non-GNU assembler that passes the asm test
correctly supports the directives.

gcc/ChangeLog:

	* configure.ac (check leb128 support): Support non-GNU assemblers
	that pass the leb128 confgure test.  Add a test for uleb128 with
	the MSB set for a 64 bit value.
	* configure: Regenerated.
---
  gcc/configure    | 6 ++++++
  gcc/configure.ac | 6 ++++++
  2 files changed, 12 insertions(+)

    # despite appearing to.
@@ -3095,6 +3098,9 @@ L2:],
      then :
      else gcc_cv_as_leb128=yes
      fi
+  else
+    # This is a non-GNU assembler, which passes the feature check.
+    gcc_cv_as_leb128=yes
    fi]],
    [AC_DEFINE(HAVE_AS_LEB128, 1,
      [Define if your assembler supports .sleb128 and .uleb128.])],

Comments

Rainer Orth Nov. 25, 2020, 10:37 a.m. UTC | #1 
Hi Iain,

> I’ve had this patch in my Darwin trees for (literally) years, it is
> relevant to
> the GCC ports that use a non-binutils assembler.
>
> At present, even if such an assembler supports LEB128,  the GCC config
> is setting HAVE_LEB128 = 0.
>
> The ports I know of that can benefit from a change here are:
[...]
> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would
>             want wider checks).

I've just manually tried the augmented test on Solaris 10-11.4, SPARC
and x86.  While the Solaris/SPARC assembler handles it just fine, the
x86 one chokes in a known way:

Assembler: 
	"/homes/ro/leb128.s", line 2 : Syntax error
	Near line: "	.uleb128 L2 - L1"

> I guess we could exclude specific ports that don’t want to use leb128 with
> a target elif in the configuration.

I'll include the patch in tonight's Solaris bootstraps for good measure,
but it seems fine to me as is.

Thanks.
        Rainer
Jeff Law Nov. 25, 2020, 5:49 p.m. UTC | #2 
On 11/25/20 2:49 AM, Iain Sandoe wrote:
> Hi,
>
> I’ve had this patch in my Darwin trees for (literally) years, it is
> relevant to
> the GCC ports that use a non-binutils assembler.
>
> At present, even if such an assembler supports LEB128,  the GCC config
> is setting HAVE_LEB128 = 0.
>
> The ports I know of that can benefit from a change here are:
>
> AIX (unaffected by this change, since the assembler [at least on
> gcc119] does
>         not support leb128 directives)
>
> Darwin (checked the various different assemblers)
>
> GCN (I can’t test this, so Andrew, please could you say if the change
>           is OK for that)
>
> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would
>             want wider checks).
>
> I guess we could exclude specific ports that don’t want to use leb128
> with
> a target elif in the configuration.
>
> OK for master?
>
> thanks
> Iain
>
> ===== commit message
>
> Some assemblers that either do not respond to --version, or are non-GNU,
> do support leb128 directives.  The current configuration test omits these
> cases and only supports GNU assemblers with a version > 2.11.
>
> The patch extends the asm test to cover one failure case present in
> assemblers based off an older version of GAS (where a 64 bit value with
> the MSB set presented to a .uleb128 directive causes a fail).
>
> This change then assumes that a non-GNU assembler that passes the asm
> test
> correctly supports the directives.
>
> gcc/ChangeLog:
>
>     * configure.ac (check leb128 support): Support non-GNU assemblers
>     that pass the leb128 confgure test.  Add a test for uleb128 with
>     the MSB set for a 64 bit value.
>     * configure: Regenerated.
OK.  Obviously if Rainer's tests show adjustment is necessary we'll have
to take care of that. 

Jeff
Rainer Orth Nov. 26, 2020, 1:08 p.m. UTC | #3 
Hi Iain,

>> The ports I know of that can benefit from a change here are:
> [...]
>> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would
>>             want wider checks).
>
> I've just manually tried the augmented test on Solaris 10-11.4, SPARC
> and x86.  While the Solaris/SPARC assembler handles it just fine, the
> x86 one chokes in a known way:
>
> Assembler: 
> 	"/homes/ro/leb128.s", line 2 : Syntax error
> 	Near line: "	.uleb128 L2 - L1"
>
>> I guess we could exclude specific ports that don’t want to use leb128 with
>> a target elif in the configuration.
>
> I'll include the patch in tonight's Solaris bootstraps for good measure,
> but it seems fine to me as is.

unfortunately, Solaris/SPARC results are miserable:

* About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all
  in the same way, it seems:

+FAIL: go.go-torture/execute/array-1.go execution,  -O0 

fatal error: DWARF underflow in .debug_line at 3266879

goroutine 1 [running, locked to thread]:
fatal error: DWARF underflow in .debug_line at 3266879
panic during panic

goroutine 1 [running, locked to thread]:
fatal error: DWARF underflow in .debug_line at 3266879
stack trace unavailable

* On top of that, I get about 80 libstdc++ failures, again all of the
  same kind:

+FAIL: libstdc++-prettyprinters/80276.cc whatis p4

type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
got: type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>

  which is confusing because the the found and expected types are
  identical.

All this happens for both 32 and 64-bit tests.

To ascertain that this is really the leb128 patch, I've reverted it in
my tree and reran the bootstrap: all those failures are gone.

So without further investigation, we cannot use the leb128 directives
with Solaris/SPARC as.

	Rainer
Iain Sandoe Nov. 26, 2020, 1:17 p.m. UTC | #4 
Hi Rainer,

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:

>>> The ports I know of that can benefit from a change here are:
>> [...]
>>> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would
>>>            want wider checks).
>>
>> I've just manually tried the augmented test on Solaris 10-11.4, SPARC
>> and x86.  While the Solaris/SPARC assembler handles it just fine, the
>> x86 one chokes in a known way:
>>
>> Assembler:
>> 	"/homes/ro/leb128.s", line 2 : Syntax error
>> 	Near line: "	.uleb128 L2 - L1"
>>
>>> I guess we could exclude specific ports that don’t want to use leb128  
>>> with
>>> a target elif in the configuration.
>>
>> I'll include the patch in tonight's Solaris bootstraps for good measure,
>> but it seems fine to me as is.
>
> unfortunately, Solaris/SPARC results are miserable:
>
> * About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all
>  in the same way, it seems:
>
> +FAIL: go.go-torture/execute/array-1.go execution,  -O0
>
> fatal error: DWARF underflow in .debug_line at 3266879
>
> goroutine 1 [running, locked to thread]:
> fatal error: DWARF underflow in .debug_line at 3266879
> panic during panic
>
> goroutine 1 [running, locked to thread]:
> fatal error: DWARF underflow in .debug_line at 3266879
> stack trace unavailable

go is stil not implemented for Darwin, so I have no comparison there.

> * On top of that, I get about 80 libstdc++ failures, again all of the
>  same kind:
>
> +FAIL: libstdc++-prettyprinters/80276.cc whatis p4
>
> type =  
> std::unique_ptr<std::vector<std::unique_ptr<std::list<std::basic_string<char,  
> std::char_traits<char>, std::allocator<char> >>[]>>[99]>
> got: type =  
> std::unique_ptr<std::vector<std::unique_ptr<std::list<std::basic_string<char,  
> std::char_traits<char>, std::allocator<char> >>[]>>[99]>
>
>  which is confusing because the the found and expected types are
>  identical.

so some breakage in RTTI .. I suppose.

> All this happens for both 32 and 64-bit tests.
>
> To ascertain that this is really the leb128 patch, I've reverted it in
> my tree and reran the bootstrap: all those failures are gone.
>
> So without further investigation, we cannot use the leb128 directives
> with Solaris/SPARC as.

I think Andrew was running GCN (not sure of the results there)

- but, I suppose that the simplest modification is to do

elif … target is darwin

and make it so that other (non-GNU-as) platforms have to opt in.

I’ll make a version that does this and test it locally.

thanks for checking,
Iain
Rainer Orth Nov. 26, 2020, 1:26 p.m. UTC | #5 
Hi Iain,

>> unfortunately, Solaris/SPARC results are miserable:
>>
>> * About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all
>>  in the same way, it seems:
>>
>> +FAIL: go.go-torture/execute/array-1.go execution,  -O0
>>
>> fatal error: DWARF underflow in .debug_line at 3266879
>>
>> goroutine 1 [running, locked to thread]:
>> fatal error: DWARF underflow in .debug_line at 3266879
>> panic during panic
>>
>> goroutine 1 [running, locked to thread]:
>> fatal error: DWARF underflow in .debug_line at 3266879
>> stack trace unavailable
>
> go is stil not implemented for Darwin, so I have no comparison there.

I suspect this is not about Go in particular, but about a buggy
assembler ;-)  The Solaris as track record isn't really the best,
unfortunately.

I just had a quick look at the stacktrace at the failure point

Thread 2 hit Breakpoint 1, 0xfeb60cc8 in runtime.throw (s=...) at  /vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go:33837
33837	 /vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go: No such file or directory.
(gdb) where
#0  0xfeb60cc8 in runtime.throw (s=...) at  /vol/gcc/src/hg/master/local/libgo/go/runtime/internal/sys/intrinsics_common.go:33837
#1  0xfe6a1c0c in runtime_throw (s=0x64d100 "DWARF underflow in .debug_line at 3266879") at /vol/gcc/src/hg/master/local/libgo/runtime/panic.c:13
#2  0xfe69ea18 in error_callback (data=0x64d9e0, errnum=0, msg=0x64d100 "DWARF underflow in .debug_line at 3266879") at /vol/gcc/src/hg/master/local/libgo/runtime/go-callers.c:68
#3  error_callback (data=0x64d9e0, msg=0x64d100 "DWARF underflow in .debug_line at 3266879", errnum=0) at /vol/gcc/src/hg/master/local/libgo/runtime/go-callers.c:211
#4  0xfecd22d0 in dwarf_buf_error (msg=<optimized out>, buf=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:16103
#5  require (count=<optimized out>, buf=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:433
#6  advance (count=<optimized out>, buf=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:446
#7  read_line_program (vec=<optimized out>, line_buf=<optimized out>, hdr=<optimized out>, u=<optimized out>, ddata=<optimized out>, state=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:2819
#8  read_line_info (lines_count=<synthetic pointer>, lines=<synthetic pointer>, hdr=<error reading variable: DWARF expression error: ran off end of buffer reading sleb128 value>, u=<optimized out>, data=<optimized out>, error_callback=<optimized out>, ddata=0xed188510, state=0xff188000) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:2951
#9  dwarf_lookup_pc (state=0xff188000, ddata=0xed188510, pc=<optimized out>, callback=<optimized out>, error_callback=<optimized out>, data=<optimized out>, found=<optimized out>) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:3732
#10 0xfecd3300 in dwarf_fileline (state=0xff188000, pc=4273447611, callback=0xfe69ec04 <callback>, error_callback=0xfe69e9e4 <error_callback>, data=0x64d9e0) at /vol/gcc/src/hg/master/local/libbacktrace/dwarf.c:20031
#11 0xfecd4160 in backtrace_pcinfo (state=0xff188000, pc=4273447611, callback=0xfe69ec04 <callback>, error_callback=0xfe69e9e4 <error_callback>, data=0x64d9e0) at /vol/gcc/src/hg/master/local/libbacktrace/fileline.c:973
#12 0xfecd4714 in unwind (context=<optimized out>, vdata=0x64d964) at /vol/gcc/src/hg/master/local/libbacktrace/backtrace.c:91
#13 0xff13c8d4 in _Unwind_Backtrace (trace=0xfecd4688 <unwind>, trace_argument=0x64d964) at /builds2/ulhg/nightly_85/components/gcc10/gcc-10.2.0/libgcc/unwind.inc:307
#14 0xfecd479c in backtrace_full (state=0xff188000, skip=0, callback=0xfe69ec04 <callback>, error_callback=0xfe69e9e4 <error_callback>, data=0x64d9e0) at /vol/gcc/src/hg/master/local/libbacktrace/backtrace.c:127
[...]

  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.

>> All this happens for both 32 and 64-bit tests.
>>
>> To ascertain that this is really the leb128 patch, I've reverted it in
>> my tree and reran the bootstrap: all those failures are gone.
>>
>> So without further investigation, we cannot use the leb128 directives
>> with Solaris/SPARC as.
>
> I think Andrew was running GCN (not sure of the results there)
>
> - but, I suppose that the simplest modification is to do
>
> elif … target is darwin
>
> and make it so that other (non-GNU-as) platforms have to opt in.

Agreed: that's certainly the safest option given that we're in stage3.
While it would be nice to be able to use the leb128 directives, I
wouldn't consider this crucial.

> I’ll make a version that does this and test it locally.

Great, thanks.

	Rainer
Jakub Jelinek Nov. 26, 2020, 1:30 p.m. UTC | #6 
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 things
go wrong, and then just look at the assembly and whether it matches what as
made out of it?

	Jakub
Iain Sandoe Nov. 26, 2020, 2:48 p.m. UTC | #7 
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:

>>> unfortunately, Solaris/SPARC results are miserable:
>>>

>>> So without further investigation, we cannot use the leb128 directives
>>> with Solaris/SPARC as.
>>
>> I think Andrew was running GCN (not sure of the results there)
>>
>> - but, I suppose that the simplest modification is to do
>>
>> elif … target is darwin
>>
>> and make it so that other (non-GNU-as) platforms have to opt in.
>
> Agreed: that's certainly the safest option given that we're in stage3.
> While it would be nice to be able to use the leb128 directives, I
> wouldn't consider this crucial.
>
>> I’ll make a version that does this and test it locally.
>
> Great, thanks.

testing this (which ought to be easy for GCN to opt into if wanted):

diff --git a/gcc/configure.ac b/gcc/configure.ac
index cc27d099f00..d9aa36d7f24 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -3114,6 +3114,8 @@ AC_MSG_RESULT($gcc_cv_ld_ro_rw_mix)
  gcc_AC_INITFINI_ARRAY
 
  # Check if we have .[us]leb128, and support symbol arithmetic with it.
+# Some assemblers based on older GAS have a bug when the MSB is set for
+# a 64b value and used in a uleb128.
  gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128,
    [elf,2,11,0],,
  [      .data
@@ -3121,6 +3123,7 @@ gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128],  
gcc_cv_as_leb128,
  L1:
         .uleb128 1280
         .sleb128 -1010
+       .uleb128 0x8000000000000000
  L2:],
  [[# GAS versions before 2.11 do not support uleb128,
    # despite appearing to.
@@ -3137,6 +3140,13 @@ L2:],
      then :
      else gcc_cv_as_leb128=yes
      fi
+  else
+    # Allow targets to opt in if the leb128 test above is adequate to
+    # indicate it may be used.
+    case "$target" in
+      *-*-darwin*) gcc_cv_as_leb128=yes ;;
+      *) ;;
+    esac
    fi]],
    [AC_DEFINE(HAVE_AS_LEB128, 1,
      [Define if your assembler supports .sleb128 and .uleb128.])],
Andrew Stubbs Nov. 26, 2020, 2:52 p.m. UTC | #8 
On 26/11/2020 14:48, Iain Sandoe wrote:
> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
> 
>>>> unfortunately, Solaris/SPARC results are miserable:
>>>>
> 
>>>> So without further investigation, we cannot use the leb128 directives
>>>> with Solaris/SPARC as.
>>>
>>> I think Andrew was running GCN (not sure of the results there)
>>>
>>> - but, I suppose that the simplest modification is to do
>>>
>>> elif … target is darwin
>>>
>>> and make it so that other (non-GNU-as) platforms have to opt in.
>>
>> Agreed: that's certainly the safest option given that we're in stage3.
>> While it would be nice to be able to use the leb128 directives, I
>> wouldn't consider this crucial.
>>
>>> I’ll make a version that does this and test it locally.
>>
>> Great, thanks.
> 
> testing this (which ought to be easy for GCN to opt into if wanted):

I've tested the original patch, and there were no new failures for GCN.

Andrew
Rainer Orth Nov. 26, 2020, 3:07 p.m. UTC | #9 
Hi Jakub,

> 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 things
> go wrong, and then just look at the assembly and whether it matches what as
> 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

--- build.no-leb128/sparc-sun-solaris2.11/libgo/errors.o.readelf-wi     2020-11-26 14:55:17.792533040 +0000
+++ build.leb128/sparc-sun-solaris2.11/libgo/errors.o.readelf-wi        2020-11-26 14:54:59.099964700 +0000
@@ -957,7 +957,7 @@
     <7b1>   DW_AT_decl_line   : 89
     <7b2>   DW_AT_decl_column : 2
     <7b3>   DW_AT_type        : <0x314>
-    <7b7>   DW_AT_location    : 3 byte block: 91 94 7f         (DW_OP_fbreg: -108)
+    <7b7>   DW_AT_location    : 3 byte block: 91 54 7f         (DW_OP_fbreg: -44; DW_OP_breg15 (r15): 0)
  <3><7bb>: Abbrev Number: 35 (DW_TAG_lexical_block)
     <7bc>   DW_AT_ranges      : 0x98
     <7c0>   DW_AT_sibling     : <0x806>

The corresponding assembler is

        .byte   0x3     ! uleb128 0x3; DW_AT_location
        .byte   0x91    ! DW_OP_fbreg
        .byte   0x94,0x7f       ! sleb128 -108

without leb128 directives and

        .uleb128 0x3    ! DW_AT_location
        .byte   0x91    ! DW_OP_fbreg
        .sleb128 -108

with them.  Solaris/SPARC as emits 54 7f for the .sleb128, not 94 7f.

No wonder things go astray from there...

	Rainer
Iain Sandoe Nov. 26, 2020, 8:28 p.m. UTC | #10 
Hi folks,

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  
>> things
>> go wrong, and then just look at the assembly and whether it matches what  
>> as
>> 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  
functional
uleb128 - so I don’t want to punt on those for absence of it.  We already  
check for
otool elsewhere.

thoughts?

Iain

-----

# 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,
   [elf,2,11,0],,
[	.data
	.uleb128 L2 - L1
L1:
	.uleb128 1280
	.sleb128 -1010
L2:
	.uleb128 0x8000000000000000
],
[[
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
    gcc_cv_as_leb128=yes
  fi
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
    gcc_cv_as_leb128=yes
  fi
else
   # play safe, assume the assembler is broken.
   :
fi
]],
   [AC_DEFINE(HAVE_AS_LEB128, 1,
     [Define if your assembler supports .sleb128 and .uleb128.])],
   [AC_DEFINE(HAVE_AS_LEB128, 0,
     [Define if your assembler supports .sleb128 and .uleb128.])])
Rainer Orth Nov. 26, 2020, 9:39 p.m. UTC | #11 
Hi Iain,

> 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
> functional
> uleb128 - so I don’t want to punt on those for absence of it.  We already
> check for
> otool elsewhere.
>
> thoughts?

LGTM, with one nit:

> [[
> if test "x$gcc_cv_objdump" != x; then
>  if $gcc_cv_objdump --full-contents conftest.o 2>/dev/null \

I'd use $gcc_cv_objdump -s here (maybe adding -j .data), matching the
other equivalent objdump invocations in gcc/configure.

	Rainer
Iain Sandoe Nov. 26, 2020, 9:43 p.m. UTC | #12 
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>>
>> 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
>> functional
>> uleb128 - so I don’t want to punt on those for absence of it.  We already
>> check for
>> otool elsewhere.
>>
>> thoughts?
>
> LGTM, with one nit:
>
>> [[
>> if test "x$gcc_cv_objdump" != x; then
>> if $gcc_cv_objdump --full-contents conftest.o 2>/dev/null \
>
> I'd use $gcc_cv_objdump -s here (maybe adding -j .data), matching the
> other equivalent objdump invocations in gcc/configure.

OK - I need to check on compatibility between GNU objdump and LLVM objdump.
(since newer Darwin and GCN will be using the latter).

-s might work OK since we only have one section, but -j is problematic wit
different section naming conventions.

corollary: one should not assume that other invocations of objdump in  
configure
are working as expected if the objdump is the LLVM one.

cheers
Iain
diff mbox series

Patch

diff --git a/gcc/configure.ac b/gcc/configure.ac
index b410428b4fc..8a1aa95f01b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -3072,6 +3072,8 @@  AC_MSG_RESULT($gcc_cv_ld_ro_rw_mix)
  gcc_AC_INITFINI_ARRAY
 
  # Check if we have .[us]leb128, and support symbol arithmetic with it.
+# Some assemblers based on older GAS have a bug when the MSB is set for
+# a 64b value and used in a uleb128.
  gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128], gcc_cv_as_leb128,
    [elf,2,11,0],,
  [	.data
@@ -3079,6 +3081,7 @@  gcc_GAS_CHECK_FEATURE([.sleb128 and .uleb128],  
gcc_cv_as_leb128,
  L1:
  	.uleb128 1280
  	.sleb128 -1010
+	.uleb128 0x8000000000000000
  L2:],
  [[# GAS versions before 2.11 do not support uleb128,