r207471 submitted against devel/powerpc64-gcc for _Unwind_RaiseException's internal unbounded looping; matching up with 207359 against base system
> #include
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {} // same result without &
> return 0;
> }
compiled under devel/powerpc64-gcc (gcc 5.3 based) on a FreeBSD
projects/clang380-import (-r295902, for example) that was also built
(buildworld/buildkernel) with the same devel/powerpc64-gcc demonstrates:
_Unwind_RaiseException never returns because it is stuck in a unbounded loop.
[clang380-import vs. 11.0-CURRENT is not likely to be a big distinction here.
PowerPC64 might be or might not be relative to g++ 5.3 .]
The cause has been tracked down to incomplete (and so inaccurate) .eh_frame
information as shown below.
I use a mix of . . .
# /usr/local/bin/objdump -d --prefix-addresses libcxxrt.so.1.full
output and the matching . . .
# dwarfdump -v -v -F libcxxrt.so.1.full | more
output to show this.
00015350 <.__cxa_end_catch+0x490> addir3,r31,88
00015354 <.__cxa_end_catch+0x494> addir10,r10,1
00015358 <.__cxa_end_catch+0x498> stw r10,48(r9)
0001535c <.__cxa_end_catch+0x49c> bl 9ae0
<0017.plt_call._Unwind_RaiseException@@GCC_3.0>
00015360 <.__cxa_end_catch+0x4a0> ld r2,40(r1)
00015364 <.__cxa_end_catch+0x4a4> addir1,r1,128
00015368 <.__cxa_end_catch+0x4a8> mr r4,r31
vs.
<0><0x00015050:0x00015310>
0x00015050:
0x0001506c:
0x000150b8:
0x000150d0:
0x000150e0:
Of note here is that the return "address" from the bl context is correctly
identified as 00015360 by the .eh_frame information and its
interpretation.
But also of note there is that 00015360 and 00015364 also are
identified as having 00015360 as their return address (part of the same
block of code as the bl as things are classified above). (That is what the live
code actually generates, up to relocation issues changing addresses.)
So when _Unwind_RaiseException attempts to walk up the stack from itself for
the first pass up the stack it gets to 00015360.
And from there it gets to 00015360 and loops.
And from there it gets to 00015360 and loops.
And from there it gets to 00015360 and loops.
And from there it gets to 00015360 and loops.
. . .
This code/.eh_frame pattern occurs again a little later (and this is where the
original problem was observed for this low-level-detail view). . .
00015380 <.__cxa_end_catch+0x4c0> addis r8,r2,-1
00015384 <.__cxa_end_catch+0x4c4> addir3,r31,88
00015388 <.__cxa_end_catch+0x4c8> ld r10,28144(r8)
0001538c <.__cxa_end_catch+0x4cc> std r10,32(r31)
00015390 <.__cxa_end_catch+0x4d0> lwz r10,48(r9)
00015394 <.__cxa_end_catch+0x4d4> addir10,r10,1
00015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9)
0001539c <.__cxa_end_catch+0x4dc> bl 9ae0
<0017.plt_call._Unwind_RaiseException@@GCC_3.0>
000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1)
000153a4 <.__cxa_end_catch+0x4e4> addir1,r1,128
000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31
000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1)
vs.
<0><0x00015310:0x000153dc>
0x00015310:
0x00015318:
0x00015324:
0x00015368:
0x00015378:
0x00015380:
0x000153a8:
0x000153b8:
0x000153c0:
This leads to (during _Unwind_RaiseException's loop):
. . .
And from there it gets to 000153a0 and loops.
And from there it gets to 000153a0 and loops.
And from there it gets to 000153a0 and loops.
And from there it gets to 000153a0 and loops.
. . .
00015360 and 000153a0 should each be starts of new code-block
ranges for identifying a different return address.
So C++ exception handling is broken for FreeBSD when buildworld is based on
devel/powerpc65-gcc: libcxxrt has examples of the error in it.
I'd expect that gcc5 (5.3) has other contexts where it does not get the correct
return address via its .eh_frame generated materials, at least for powerpc64.
[207359 might be considered replaced by 207471.]
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling
[In part: My references to libc++ should have been to libcxxrt. Also:
devel/powerpc64-gcc produced the incomplete .eh_frame information.]
On 2016-Feb-24, at 5:07 PM, Mark Millard wrote:
>
> [Deliberate top posting an history removal for significant new information.]
>
> I've finally traced the low level details of the powerpc64
> _Unwind_RaiseException stuck looping failure. What I've submitted into the
> defect is basically that for clang 3.8.0's .eh_frame information generation
> in libcxxrt's code there is an error in the form of an incompleteness. . .
>
>
> Starting from the observed low-level evidence based on observation via gdb
> and such:
>
> A backtrace while stopped during the unbounded looping is:
>
>> #0 uw_update_context (context=context@entry=0xccf0,
>> fs=fs@entry=0xc370) at
>> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1371
>> #1 0x501cb95c in _Unwind_RaiseException (exc=0x50815058) at
>> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:126
>> #2 0x5016e3a0 in throw_exception (ex=0x50815000) at
>> /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:751
>> #3 0x1d50 in main () at exception_test.cpp:5
>
> _Unwind_RaiseException never returns for source code that looks like:
>
>> #include
>>
>> int main(void)
>> {
>>try { throw std::exception(); }
>>catch (std::exception& e) {}
>>return 0;
>> }
>
> where in /usr/lib/libc++.so.1 there is:
>
>> 736 static void throw_exception(__cxa_exception *ex)
>> 737 {
>> . . .
>> 751 _Unwind_Reason_Code err =
>> _Unwind_RaiseException(&ex->unwindHeader);
>> . . .
>> 756 }
>
> The unbounded loop in _Unwind_RaiseException is in the code:
>
>> 85 _Unwind_Reason_Code
>> 86 _Unwind_RaiseException(struct _Unwind_Exception *exc)
>> 87 {
>> 88 struct _Unwind_Context this_context, cur_context;
>> 89 _Unwind_Reason_Code code;
>> 90
>> 91 /* Set up this_context to describe the current stack frame. */
>> 92 uw_init_context (&this_context);
>> 93 cur_context = this_context;
>> 94
>> 95 /* Phase 1: Search. Unwind the stack, calling the personality routine
>> 96with the _UA_SEARCH_PHASE flag set. Do not modify the stack yet.
>> */
>> 97 while (1)
>> 98 {
>> 99 _Unwind_FrameState fs;
>> 100
>> 101/* Set up fs to describe the FDE for the caller of cur_context.
>> The
>> 102 first time through the loop, that means __cxa_throw. */
>> 103code = uw_frame_state_for (&cur_context, &fs);
>> . . .
>> 125/* Update cur_context to describe the same frame as fs. */
>> 126uw_update_context (&cur_context, &fs);
>> 127 }
>> . . .
>> 140 }
>
> The uw_update_context call is doing the following before returning:
>
>> 1367 /* Compute the return address now, since the return address column
>> 1368 can change from frame to frame. */
>> 1369 context->ra = __builtin_extract_return_addr
>> 1370 (_Unwind_GetPtr (context, fs->retaddr_column));
>
> with context->ra before and after the call both being 0x5016e3a0 . In fact it
> was 0x5016e3a0 for the prior uw_frame_state_for call as well and continues to
> be so each loop iteration once the problem starts.
>
> As for the code around 0x5016e3a0:
>
>> 0x5016e398 :stw
>> r10,48(r9)
>> 0x5016e39c :bl
>> 0x50162ae0 <0017.plt_call._Unwind_RaiseException@@GCC_3.0>
>> 0x5016e3a0 :ld
>> r2,40(r1)
>> 0x5016e3a4 :addi
>> r1,r1,128
>> 0x5016e3a8 :mr
>> r4,r31
>> 0x5016e3ac :ld
>> r0,16(r1)
>
> From /usr/local/bin/objdump for FreeBSD projects/clang380-import -r295902's
> /usr/lib/libc++.so.1 for the same code (to match up with the .eh_frame dwarf
> information):
>
>> 00015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9)
>> 0001539c <.__cxa_end_catch+0x4dc> bl 9ae0
>>
>> 000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1)
>> 000153a4 <.__cxa_end_catch+0x4e4> addir1,r1,128
>> 000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31
>> 000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1)
>
> The code block above from 153a0 up to 153a8 is being given 153a0 as its
> "return address" (context->ra) by uw_update_context via interpreting the
> dwarf .eh_frame information. So once in that range there it never leaves that
> range.
>
> The relevant dwarfdump output spanning that area is:
> (Note that 153a0 up to 153a8 is part of the range that includes the bl to
> _Unwind_RaiseException .)
>
>> <0><0x00015310:0x000153dc><>> 0x0034>
>>0x00015310:
>>0x00015318:
>>0x00015324:
>>0x00015368:
>>0x00015378:
>>0x00015380:
>>0x000153a8:
>>0x000153b8:
>>0x000153c0:
>> fde section offset 4312 0x10d8 cie offset for fde: 4316 0x10dc
>> 0 DW_CFA_advance
Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling
[Deliberate top posting an history removal for significant new information.]
I've finally traced the low level details of the powerpc64
_Unwind_RaiseException stuck looping failure. What I've submitted into the
defect is basically that for clang 3.8.0's .eh_frame information generation in
libcxxrt's code there is an error in the form of an incompleteness. . .
Starting from the observed low-level evidence based on observation via gdb and
such:
A backtrace while stopped during the unbounded looping is:
> #0 uw_update_context (context=context@entry=0xccf0,
> fs=fs@entry=0xc370) at
> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1371
> #1 0x501cb95c in _Unwind_RaiseException (exc=0x50815058) at
> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:126
> #2 0x5016e3a0 in throw_exception (ex=0x50815000) at
> /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:751
> #3 0x1d50 in main () at exception_test.cpp:5
_Unwind_RaiseException never returns for source code that looks like:
> #include
>
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {}
> return 0;
> }
where in /usr/lib/libc++.so.1 there is:
> 736 static void throw_exception(__cxa_exception *ex)
> 737 {
> . . .
> 751 _Unwind_Reason_Code err =
> _Unwind_RaiseException(&ex->unwindHeader);
> . . .
> 756 }
The unbounded loop in _Unwind_RaiseException is in the code:
> 85_Unwind_Reason_Code
> 86_Unwind_RaiseException(struct _Unwind_Exception *exc)
> 87{
> 88 struct _Unwind_Context this_context, cur_context;
> 89 _Unwind_Reason_Code code;
> 90
> 91 /* Set up this_context to describe the current stack frame. */
> 92 uw_init_context (&this_context);
> 93 cur_context = this_context;
> 94
> 95 /* Phase 1: Search. Unwind the stack, calling the personality routine
> 96 with the _UA_SEARCH_PHASE flag set. Do not modify the stack yet.
> */
> 97 while (1)
> 98{
> 99 _Unwind_FrameState fs;
> 100
> 101 /* Set up fs to describe the FDE for the caller of cur_context.
> The
> 102first time through the loop, that means __cxa_throw. */
> 103 code = uw_frame_state_for (&cur_context, &fs);
> . . .
> 125 /* Update cur_context to describe the same frame as fs. */
> 126 uw_update_context (&cur_context, &fs);
> 127 }
> . . .
> 140 }
The uw_update_context call is doing the following before returning:
> 1367/* Compute the return address now, since the return address column
> 1368 can change from frame to frame. */
> 1369context->ra = __builtin_extract_return_addr
> 1370 (_Unwind_GetPtr (context, fs->retaddr_column));
with context->ra before and after the call both being 0x5016e3a0 . In fact it
was 0x5016e3a0 for the prior uw_frame_state_for call as well and continues to
be so each loop iteration once the problem starts.
As for the code around 0x5016e3a0:
>0x5016e398 :stw
> r10,48(r9)
>0x5016e39c :bl
> 0x50162ae0 <0017.plt_call._Unwind_RaiseException@@GCC_3.0>
>0x5016e3a0 :ld
> r2,40(r1)
>0x5016e3a4 :addi
> r1,r1,128
>0x5016e3a8 :mr
> r4,r31
>0x5016e3ac :ld
> r0,16(r1)
From /usr/local/bin/objdump for FreeBSD projects/clang380-import -r295902's
/usr/lib/libc++.so.1 for the same code (to match up with the .eh_frame dwarf
information):
> 00015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9)
> 0001539c <.__cxa_end_catch+0x4dc> bl 9ae0
>
> 000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1)
> 000153a4 <.__cxa_end_catch+0x4e4> addir1,r1,128
> 000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31
> 000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1)
The code block above from 153a0 up to 153a8 is being given 153a0 as its "return
address" (context->ra) by uw_update_context via interpreting the dwarf
.eh_frame information. So once in that range there it never leaves that range.
The relevant dwarfdump output spanning that area is:
(Note that 153a0 up to 153a8 is part of the range that includes the bl to
_Unwind_RaiseException .)
> <0><0x00015310:0x000153dc><> aug data len 0x0>
> 0x00015310:
> 0x00015318:
> 0x00015324:
> 0x00015368:
> 0x00015378:
> 0x00015380:
> 0x000153a8:
> 0x000153b8:
> 0x000153c0:
> fde section offset 4312 0x10d8 cie offset for fde: 4316 0x10dc
> 0 DW_CFA_advance_loc 8 (2 * 4)
> 1 DW_CFA_register r65 = r0
> 4 DW_CFA_offset r31 -8 (1 * -8)
> 6 DW_CFA_advance_loc 12 (3 * 4)
> 7 DW_CFA_def_cfa_offset 128
> 10 DW_CFA_offset_extended_sf r65 16 (-2 * -8)
> 13 DW_CFA_advance_loc 68 (17 * 4)
> 14 DW_CFA_remember_sta
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #12 from fernando.apesteg...@gmail.com --- (In reply to Dimitry Andric from comment #11) What strikes me is that the very same software works on FreeBSD 9.x and 10.x without issues (http://portsmon.freebsd.org/portoverview.py?category=cad&portname=openvsp). So something must have changed in libc++. I'm afraid we can break other software as stupid as they can be using names. I think it's worth having a look at what it changed around July 2015 that was when the port started failing. I'm working on the port of OpenVSP 3.0 but it requires the addition of other ports first and it will take a while. In the meantime I would rather compile OpenVSP with gcc as the patch purposes instead of working on a new patch for the code. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #11 from Dimitry Andric --- (In reply to fernando.apesteguia from comment #10) > (In reply to Raphael Kubo da Costa from comment #9) > > I think it is not doing the right thing. Have a look at this[1]. std::array > is a feature introduced in C++11 and the software is not using C++11 > features. > > [1] http://www.cplusplus.com/reference/array/array/ Well, try to report this to libc++ upstream, and see what they say. I don't much feel like hacking our local copy with some change that will conflict with whatever upstream is doing, let alone that we cannot do anything about the existing copies of libc++ out there. If openvsp is legacy software, it should be no problem to put a small patch in which fixes this. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #10 from fernando.apesteg...@gmail.com --- (In reply to Raphael Kubo da Costa from comment #9) I think it is not doing the right thing. Have a look at this[1]. std::array is a feature introduced in C++11 and the software is not using C++11 features. [1] http://www.cplusplus.com/reference/array/array/ -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #9 from Raphael Kubo da Costa --- I agree, but this is legacy software (version 3 doesn't even have its own array implementation anymore as far as I can see) that won't be changed upstream. My question is if libc++ is right in declaring std::array when not in C++11 mode or if this clash shouldn't happen at all, even if what the program does is dangerous. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #8 from Dimitry Andric --- I think the program should not try to use both "using namespace std", and then use a reserved C++11 name. It should either drop the "using namespace std", or rename its own array to e.g. openvsp_array or even better, ovenvsp::array. In general, try to avoid "using namespace std". -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
Konstantin Belousov writes:
> On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote:
>> On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote:
>> >
>> > I'm reviewing an update to the textproc/miller port in bug 207194, and
>> > noticed it does some ugly things in post-configure to seemingly
>> > work around the following problem (on 11-HEAD at least):
>> >
>> > % echo 'int main(void) { return 0; }' > foo.c
>> > % clang -pg foo.c -lm
>> > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc)
>> > //lib/libc.so.7: could not read symbols: Bad value
>> > cc: error: linker command failed with exit code 1 (use -v to see
>> > invocation)
>>
>> Try using: clang -pg foo.c -lm_p
>>
>> That works for me (also with gcc).
>
> It probably not quite works, in the sense that it resolves _end to
> something not correctly provided by libm_p.a. In other words, sbrk(),
> if used for anything, would be broken.
It at least "works" in the sense that clang doesn't fail; however, in
addition to kib's point this doesn't look optimal from a ports
perspective, as it requires giving special treatment to certain targets
and possibly hacking the build system in different ports.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
Konstantin Belousov writes:
> This is probably not a clang bug, but could be. More likely it is ld problem.
> I do not want to dig into the issue, but I can provide you some points to
> look at further.
>
> The _end symbol is magic, it is defined as the address of the last byte
> + 1 of zero-initialized data section (.bss). But the symbol is not
> provided by any object file participating in the linkage of the binary,
> instead it is created by the linker after all sections are combined in
> the segments and segments are laid out.
>
> The symbol is creation requested by the linker script, look at the
> /usr/libdata/ldscripts for them, first line of the file contains
> comment explaining which final binary format is served by the each
> script.
>
> We are aware that binutils 2.25.1 ld for aarch64 has bug where _end is
> not exported from executable, I was not able to track the bug.
>
> To diagnose your issue, look up which linker script is used for -pg
> linking, look for the _end symbol there. If it is properly requested,
> then the bug is in base linker.
With and without -pg, the linker script being used is elf_x86_64_fbsd.xc
("Script for -z combreloc: combine and sort reloc sections"). It does
contain an entry for _end:
182 _end = .; PROVIDE (end = .);
lang/gcc with ld from devel/binutils also fails on HEAD:
/usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to
symbol '_end'
//lib/libc.so.7: error adding symbols: DSO missing from command line
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207253] cad/openvsp: Fix in 11-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added CC||freebsd-toolchain@FreeBSD.o ||rg --- Comment #7 from Raphael Kubo da Costa --- +freebsd-toolchain. Can someone take a look at comment #6 and check if libc++ is working as intended? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote:
> On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote:
> >
> > I'm reviewing an update to the textproc/miller port in bug 207194, and
> > noticed it does some ugly things in post-configure to seemingly
> > work around the following problem (on 11-HEAD at least):
> >
> > % echo 'int main(void) { return 0; }' > foo.c
> > % clang -pg foo.c -lm
> > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc)
> > //lib/libc.so.7: could not read symbols: Bad value
> > cc: error: linker command failed with exit code 1 (use -v to see
> > invocation)
>
> Try using: clang -pg foo.c -lm_p
>
> That works for me (also with gcc).
It probably not quite works, in the sense that it resolves _end to
something not correctly provided by libm_p.a. In other words, sbrk(),
if used for anything, would be broken.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote:
>
> I'm reviewing an update to the textproc/miller port in bug 207194, and
> noticed it does some ugly things in post-configure to seemingly
> work around the following problem (on 11-HEAD at least):
>
> % echo 'int main(void) { return 0; }' > foo.c
> % clang -pg foo.c -lm
> /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc)
> //lib/libc.so.7: could not read symbols: Bad value
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
Try using: clang -pg foo.c -lm_p
That works for me (also with gcc).
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: clang -pg, libm and the _end symbol
On Wed, Feb 24, 2016 at 12:27:03PM +0100, Raphael Kubo da Costa wrote:
> I'm reviewing an update to the textproc/miller port in bug 207194, and
> noticed it does some ugly things in post-configure to seemingly
> work around the following problem (on 11-HEAD at least):
>
> % echo 'int main(void) { return 0; }' > foo.c
> % clang -pg foo.c -lm
> /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc)
> //lib/libc.so.7: could not read symbols: Bad value
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> (FWIW, using another library such as -lz instead of -lm retuls in the
> same problem)
>
> Adding LDFLAGS+=-lc to the port's Makefile would've been enough, but I'm
> not sure if it'd be just working around an actual bug, plus libtool
> automatically strips -lc from the linker invocation:
>
> 7534 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*)
> 7535 # Do not include libc due to us having libc/libc_r.
> 7536 test X-lc = "X$arg" && continue
>
> The port builds and links fine on 9.3 without any workarounds, and if I
> explicitly use ld.gold to link the above file it also works on HEAD.
>
> Is clang working as expected or is this a bug?
This is probably not a clang bug, but could be. More likely it is ld problem.
I do not want to dig into the issue, but I can provide you some points to
look at further.
The _end symbol is magic, it is defined as the address of the last byte
+ 1 of zero-initialized data section (.bss). But the symbol is not
provided by any object file participating in the linkage of the binary,
instead it is created by the linker after all sections are combined in
the segments and segments are laid out.
The symbol is creation requested by the linker script, look at the
/usr/libdata/ldscripts for them, first line of the file contains
comment explaining which final binary format is served by the each
script.
We are aware that binutils 2.25.1 ld for aarch64 has bug where _end is
not exported from executable, I was not able to track the bug.
To diagnose your issue, look up which linker script is used for -pg
linking, look for the _end symbol there. If it is properly requested,
then the bug is in base linker.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang -pg, libm and the _end symbol
I'm reviewing an update to the textproc/miller port in bug 207194, and
noticed it does some ugly things in post-configure to seemingly
work around the following problem (on 11-HEAD at least):
% echo 'int main(void) { return 0; }' > foo.c
% clang -pg foo.c -lm
/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc)
//lib/libc.so.7: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
(FWIW, using another library such as -lz instead of -lm retuls in the
same problem)
Adding LDFLAGS+=-lc to the port's Makefile would've been enough, but I'm
not sure if it'd be just working around an actual bug, plus libtool
automatically strips -lc from the linker invocation:
7534 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*)
7535 # Do not include libc due to us having libc/libc_r.
7536 test X-lc = "X$arg" && continue
The port builds and links fine on 9.3 without any workarounds, and if I
explicitly use ld.gold to link the above file it also works on HEAD.
Is clang working as expected or is this a bug?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
