* Why are dwarf2 symbols getting assigned hidden visibility?
@ 2011-01-13 7:12 John Marino
2011-01-13 8:32 ` Jonathan Wakely
2011-01-15 10:56 ` John Marino
0 siblings, 2 replies; 17+ messages in thread
From: John Marino @ 2011-01-13 7:12 UTC (permalink / raw)
To: gcc-help
I've successfully built the GNAT front-end of gcc 4.6 on several BSD
platforms. The NetBSD versions (i386 and AMD64) have a problem that I
can't figure out, and I suspect it can be fixed with a change to the
build configuration.
Although NetBSD passes its regression tests cleanly, there are some
dwarf2 functions it doesn't seem to recognize. When I listed hidden
symbols embedded in a pre-stripped gnat1 executable, here is the result:
> readelf -s gnat1 | grep HIDDEN
19135: 0000000000fc68c0 389 FUNC LOCAL HIDDEN 11 _Unwind_Find_FDE
19136: 0000000000fc4dc0 21 FUNC LOCAL HIDDEN 11 _Unwind_GetIPInfo
19137: 0000000000fc4db0 8 FUNC LOCAL HIDDEN 11 _Unwind_GetIP
19138: 0000000000fc66a0 38 FUNC LOCAL HIDDEN 11 __register_frame
19139: 0000000000fc52b0 241 FUNC LOCAL HIDDEN 11
_Unwind_Resume_or_Rethrow
19140: 0000000000fc4e00 8 FUNC LOCAL HIDDEN 11
_Unwind_GetRegionStart
19141: 0000000000fc53d0 155 FUNC LOCAL HIDDEN 11 _Unwind_Backtrace
19142: 0000000001299720 256 OBJECT LOCAL HIDDEN 13 __popcount_tab
19143: 0000000000fc4d50 8 FUNC LOCAL HIDDEN 11 _Unwind_GetCFA
19144: 00000000014b8820 0 OBJECT LOCAL HIDDEN 17 __DTOR_END__
19145: 00000000014b9168 0 OBJECT LOCAL HIDDEN 22 __dso_handle
19146: 0000000000fc4e60 269 FUNC LOCAL HIDDEN 11 __frame_state_for
19147: 0000000000fc6760 26 FUNC LOCAL HIDDEN 11
__register_frame_table
19148: 0000000000fc6600 130 FUNC LOCAL HIDDEN 11
__register_frame_info_bas
19149: 0000000000fc6880 5 FUNC LOCAL HIDDEN 11
__deregister_frame_info
19150: 0000000000fc51e0 193 FUNC LOCAL HIDDEN 11 _Unwind_Resume
19151: 0000000000fc53b0 26 FUNC LOCAL HIDDEN 11
_Unwind_DeleteException
19152: 0000000000fc6780 256 FUNC LOCAL HIDDEN 11
__deregister_frame_info_b
19153: 0000000000fc4f80 358 FUNC LOCAL HIDDEN 11
_Unwind_RaiseException
19154: 0000000000fc4de0 8 FUNC LOCAL HIDDEN 11 _Unwind_SetIP
19155: 0000000000fc66d0 114 FUNC LOCAL HIDDEN 11
__register_frame_info_tab
19156: 0000000000fc6890 33 FUNC LOCAL HIDDEN 11
__deregister_frame
19157: 0000000000fc4e50 8 FUNC LOCAL HIDDEN 11
_Unwind_GetTextRelBase
19158: 0000000000fc4e10 36 FUNC LOCAL HIDDEN 11
_Unwind_FindEnclosingFunc
19159: 0000000000fc4df0 8 FUNC LOCAL HIDDEN 11
_Unwind_GetLanguageSpecif
19160: 0000000000fc50f0 230 FUNC LOCAL HIDDEN 11
_Unwind_ForcedUnwind
19161: 00000000014b8a28 0 OBJECT LOCAL HIDDEN 21
_GLOBAL_OFFSET_TABLE_
19162: 0000000000fc2bf0 44 FUNC LOCAL HIDDEN 11 __popcountdi2
19163: 0000000000fc4d60 80 FUNC LOCAL HIDDEN 11 _Unwind_SetGR
19164: 0000000000fc4d00 72 FUNC LOCAL HIDDEN 11 _Unwind_GetGR
19165: 0000000000fc4e40 8 FUNC LOCAL HIDDEN 11
_Unwind_GetDataRelBase
19166: 0000000000fc6750 9 FUNC LOCAL HIDDEN 11
__register_frame_info_tab
19167: 0000000000fc6690 9 FUNC LOCAL HIDDEN 11
__register_frame_info
The other BSDs consider these symbols global. For example, here is a
subset of the same symbols taken from a stripped DragonFly BSD gnat1:
419: 0000000000fb10e0 373 FUNC GLOBAL DEFAULT 10 _Unwind_Find_FDE
582: 0000000000fad8f0 21 FUNC GLOBAL DEFAULT 10
_Unwind_GetIPInfo
920: 0000000000fad8e0 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetIP
2116: 0000000000fafb40 235 FUNC GLOBAL DEFAULT 10
_Unwind_Resume_or_Rethrow
2762: 0000000000fad930 8 FUNC GLOBAL DEFAULT 10
_Unwind_GetRegionStart
3171: 0000000000fafc50 155 FUNC GLOBAL DEFAULT 10
_Unwind_Backtrace
4035: 0000000000fad880 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetCFA
9786: 0000000000fafa60 212 FUNC GLOBAL DEFAULT 10 _Unwind_Resume
9841: 0000000000fafc30 21 FUNC GLOBAL DEFAULT 10
_Unwind_DeleteException
12631: 0000000000faf800 359 FUNC GLOBAL DEFAULT 10
_Unwind_RaiseException
13229: 0000000000fad910 8 FUNC GLOBAL DEFAULT 10 _Unwind_SetIP
15888: 0000000000fad980 8 FUNC GLOBAL DEFAULT 10
_Unwind_GetTextRelBase
16508: 0000000000fad940 36 FUNC GLOBAL DEFAULT 10
_Unwind_FindEnclosingFunc
16814: 0000000000fad920 8 FUNC GLOBAL DEFAULT 10
_Unwind_GetLanguageSpecif
17568: 0000000000faf970 230 FUNC GLOBAL DEFAULT 10
_Unwind_ForcedUnwind
18388: 0000000000fad890 75 FUNC GLOBAL DEFAULT 10 _Unwind_SetGR
19462: 0000000000fad830 72 FUNC GLOBAL DEFAULT 10 _Unwind_GetGR
20086: 0000000000fad970 8 FUNC GLOBAL DEFAULT 10
_Unwind_GetDataRelBase
1345: 0000000000fb0ec0 38 FUNC GLOBAL DEFAULT 10 __register_frame
8011: 0000000000fb0f80 26 FUNC GLOBAL DEFAULT 10
__register_frame_table
8532: 0000000000fb0e20 130 FUNC GLOBAL DEFAULT 10
__register_frame_info_bas
14325: 0000000000fb0ef0 114 FUNC GLOBAL DEFAULT 10
__register_frame_info_tab
20736: 0000000000fb0f70 9 FUNC GLOBAL DEFAULT 10
__register_frame_info_tab
20856: 0000000000fb0eb0 9 FUNC GLOBAL DEFAULT 10
__register_frame_info
9544: 0000000000fb10a0 5 FUNC GLOBAL DEFAULT 10
__deregister_frame_info
10772: 0000000000fb0fa0 256 FUNC GLOBAL DEFAULT 10
__deregister_frame_info_b
15277: 0000000000fb10b0 33 FUNC GLOBAL DEFAULT 10
__deregister_frame
3677: 0000000001284260 256 OBJECT GLOBAL DEFAULT 12 __popcount_tab
18046: 0000000000fad460 44 FUNC GLOBAL DEFAULT 10 __popcountdi2
I'm pretty well convinced that the NetBSD symbols should also be
classified as GLOBAL DEFAULT and this explains NetBSD's issue with
functions such as _Unwind_Resume and _Unwind_GetIPInfo. I've gone over
config.gcc and the various NetBSD headers many times, but I don't see
what's causing this or what omission might be causing it.
Can anybody suggest what may be wrong and how to correct it?
Thanks,
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 7:12 Why are dwarf2 symbols getting assigned hidden visibility? John Marino
@ 2011-01-13 8:32 ` Jonathan Wakely
2011-01-13 10:28 ` John Marino
2011-01-15 10:56 ` John Marino
1 sibling, 1 reply; 17+ messages in thread
From: Jonathan Wakely @ 2011-01-13 8:32 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
On 13 January 2011 07:12, John Marino <gnugcc@marino.st> wrote:
>
> The NetBSD versions (i386 and AMD64) have a problem that I can't
> figure out, and I suspect it can be fixed with a change to the build
> configuration.
I have a patch at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147
Will submit it later today
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 8:32 ` Jonathan Wakely
@ 2011-01-13 10:28 ` John Marino
2011-01-13 12:45 ` Jonathan Wakely
0 siblings, 1 reply; 17+ messages in thread
From: John Marino @ 2011-01-13 10:28 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-help
Hi Jonathan,
I already patch ginclude/stddef.h in my parallel repository so I won't
need to wait for this to get submitted to test it out. I'll just patch
my version directly.
I hope these ansi macro changes are the solution. I've wasted days
trying to figure this out already!
Thanks,
John
Jonathan Wakely wrote:
> On 13 January 2011 07:12, John Marino <gnugcc@marino.st> wrote:
>> The NetBSD versions (i386 and AMD64) have a problem that I can't
>> figure out, and I suspect it can be fixed with a change to the build
>> configuration.
>
> I have a patch at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147
>
> Will submit it later today
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 10:28 ` John Marino
@ 2011-01-13 12:45 ` Jonathan Wakely
2011-01-13 16:47 ` John Marino
0 siblings, 1 reply; 17+ messages in thread
From: Jonathan Wakely @ 2011-01-13 12:45 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
On 13 January 2011 10:28, John Marino wrote:
> Hi Jonathan,
> I already patch ginclude/stddef.h in my parallel repository so I won't need
> to wait for this to get submitted to test it out. I'll just patch my
> version directly.
Great, please let me know whether it does help or not.
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 12:45 ` Jonathan Wakely
@ 2011-01-13 16:47 ` John Marino
2011-01-13 16:55 ` Jonathan Wakely
0 siblings, 1 reply; 17+ messages in thread
From: John Marino @ 2011-01-13 16:47 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-help
Hi Jonathan,
I built a fully bootstrapped version of gcc (C and Ada) using your patch
on NetBSD x86_64. The _Unwind* functions are still showing as LOCAL
HIDDEN when I scan gnat1, so I don't believe it fixed my problem
(although it may fix another problem I saw while trying to bootstrap
NetBSD i386 yesterday, TBD).
Btw the way, your patch has a spelling error in the comment:
/* NetBSD 5 requires the I386_INSI_H and X86_64_ANSI_H checks here. */
It's ANSI, not INSI
Also, to be consistent with the prior comment, you'd want to use
_I386_ANSI_H_ (not I386_ANSI_H) and likewise _X86_64_ANSI_H_
So back to my issue, can you think of anything else that might cause
this issue with the unwind functionality?
Thanks,
John
Jonathan Wakely wrote:
> On 13 January 2011 10:28, John Marino wrote:
>> Hi Jonathan,
>> I already patch ginclude/stddef.h in my parallel repository so I won't need
>> to wait for this to get submitted to test it out. I'll just patch my
>> version directly.
>
> Great, please let me know whether it does help or not.
>
> Thanks,
>
> Jonathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 16:47 ` John Marino
@ 2011-01-13 16:55 ` Jonathan Wakely
2011-01-13 19:32 ` John Marino
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Jonathan Wakely @ 2011-01-13 16:55 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
On 13 January 2011 16:47, John Marino wrote:
>
> Btw the way, your patch has a spelling error in the comment:
> /* NetBSD 5 requires the I386_INSI_H and X86_64_ANSI_H checks here. */
>
> It's ANSI, not INSI
Yep, someone already pointed that out to me, thanks
> Also, to be consistent with the prior comment, you'd want to use
> _I386_ANSI_H_ (not I386_ANSI_H) and likewise _X86_64_ANSI_H_
The comment on the previous line says:
/* BSD/OS 3.1 and FreeBSD [23].x require the MACHINE_ANSI_H check here. */
so I was going for consistency with that line, not the ones further up the file.
> So back to my issue, can you think of anything else that might cause this
> issue with the unwind functionality?
I have no idea, sorry, I was only looking at NetBSD to fix PR 47147
Thanks for trying the patch anyway.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 16:55 ` Jonathan Wakely
@ 2011-01-13 19:32 ` John Marino
[not found] ` <4D2F5250.8020200@marino.st>
2011-01-14 1:03 ` John Marino
2 siblings, 0 replies; 17+ messages in thread
From: John Marino @ 2011-01-13 19:32 UTC (permalink / raw)
To: gcc-help
By the way, I can explain why I've been able to build NetBSD all this
time (and why the patch had no effect).
I had added this to the t-netbsd makefile a couple of months ago:
# Omit $(srcdir)/ginclude/stddef.h header file for NETBSD
# Comes from gcc/Makefile.in
USER_H = $(srcdir)/ginclude/float.h \
$(srcdir)/ginclude/iso646.h \
$(srcdir)/ginclude/stdarg.h \
$(srcdir)/ginclude/stdbool.h \
$(srcdir)/ginclude/varargs.h \
$(srcdir)/ginclude/stdfix.h \
$(EXTRA_HEADERS)
I got that from the NetBSD Pkgsrc system used for building earlier gcc versions. They've been building gcc without stddef.h for a long time.
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
[not found] ` <4D2F5250.8020200@marino.st>
@ 2011-01-13 19:41 ` Jonathan Wakely
0 siblings, 0 replies; 17+ messages in thread
From: Jonathan Wakely @ 2011-01-13 19:41 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
On 13 January 2011 19:28, John Marino wrote:
> By the way, I can explain why I've been able to build NetBSD all this time
> (and why the patch had no effect).
>
> I had added this to the t-netbsd makefile a couple of months ago:
>
> # Omit $(srcdir)/ginclude/stddef.h header file for NETBSD
> # Comes from gcc/Makefile.in
> USER_H = $(srcdir)/ginclude/float.h \
> $(srcdir)/ginclude/iso646.h \
> $(srcdir)/ginclude/stdarg.h \
> $(srcdir)/ginclude/stdbool.h \
> $(srcdir)/ginclude/varargs.h \
> $(srcdir)/ginclude/stdfix.h \
> $(EXTRA_HEADERS)
>
>
> I got that from the NetBSD Pkgsrc system used for building earlier gcc
> versions. They've been building gcc without stddef.h for a long time.
Aha! That makes sense then.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 16:55 ` Jonathan Wakely
2011-01-13 19:32 ` John Marino
[not found] ` <4D2F5250.8020200@marino.st>
@ 2011-01-14 1:03 ` John Marino
2 siblings, 0 replies; 17+ messages in thread
From: John Marino @ 2011-01-14 1:03 UTC (permalink / raw)
To: gcc-help
On 1/13/2011 5:51 PM, Jonathan Wakely wrote:
> So back to my issue, can you think of anything else that might cause this
>> issue with the unwind functionality?
> I have no idea, sorry, I was only looking at NetBSD to fix PR 47147
>
> Thanks for trying the patch anyway.
I had a complete log from one of the NetBSD builds that I got from the
unix "tee" command. I decided to do the generate another long during
the build of DragonFlyBSD to compare them.
On object files like gnat1, gnat1drv, etc, there is one difference
between the build commands. DragonFlyBSD (which works) uses an -O2 flag
and NetBSD instead uses a -fkeep-inline-functions flag. All the other
flags are common between them.
Would the use of -fkeep-inline-functions explain why the unwind
functions are linked as local in the front end?
I spent a long time looking at the configure/makefiles. I can't figure
out where the -O2/-fkeep-inline-function flag is getting assigned. Both
systems passed the test checking if it's capable of
-fkeep-inline-functions (not surprising as both systems are using recent
snapshots of gcc 4.6 to build the latest).
Hopefully I'm getting closer to solving this...
John
Thank
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-13 7:12 Why are dwarf2 symbols getting assigned hidden visibility? John Marino
2011-01-13 8:32 ` Jonathan Wakely
@ 2011-01-15 10:56 ` John Marino
2011-01-15 14:25 ` John Marino
2011-01-16 4:01 ` Ian Lance Taylor
1 sibling, 2 replies; 17+ messages in thread
From: John Marino @ 2011-01-15 10:56 UTC (permalink / raw)
To: gcc-help
I really could use some help on this issue.
After examining the build logs of both DragonFlyBSD and NetBSD, I
noticed an interesting difference between the binutils of each system.
DBSD assembler supports .weakref
NBSD assembler does not.
When reading symbols of env.o (comes from gcc/ada/env.c), there is a
weak symbol there
35: 0000000000000000 8 OBJECT WEAK HIDDEN 20
DW.ref.__gcc_personality_
unwind-c.c defines PERSONALITY_FUNCTION as __gcc_personality_v0
libgcc/config/i386/morestack.S mentions the same along with
DW.ref.__gcc_personality_v0
Could the inability of NetBSD assembler support .weakref be the
explanation for the unwind symbols to be marked as hidden on the gnat1
executable even though they are marked as global on their individual
object files?
Thanks, I'm a bit over my head on this topic.
John
On 1/13/2011 8:12 AM, John Marino wrote:
> I've successfully built the GNAT front-end of gcc 4.6 on several BSD
> platforms. The NetBSD versions (i386 and AMD64) have a problem that I
> can't figure out, and I suspect it can be fixed with a change to the
> build configuration.
>
> Although NetBSD passes its regression tests cleanly, there are some
> dwarf2 functions it doesn't seem to recognize. When I listed hidden
> symbols embedded in a pre-stripped gnat1 executable, here is the result:
>
> > readelf -s gnat1 | grep HIDDEN
> 19135: 0000000000fc68c0 389 FUNC LOCAL HIDDEN 11
> _Unwind_Find_FDE
> 19136: 0000000000fc4dc0 21 FUNC LOCAL HIDDEN 11
> _Unwind_GetIPInfo
> 19137: 0000000000fc4db0 8 FUNC LOCAL HIDDEN 11 _Unwind_GetIP
> 19138: 0000000000fc66a0 38 FUNC LOCAL HIDDEN 11
> __register_frame
> 19139: 0000000000fc52b0 241 FUNC LOCAL HIDDEN 11
> _Unwind_Resume_or_Rethrow
> 19140: 0000000000fc4e00 8 FUNC LOCAL HIDDEN 11
> _Unwind_GetRegionStart
> 19141: 0000000000fc53d0 155 FUNC LOCAL HIDDEN 11
> _Unwind_Backtrace
> 19142: 0000000001299720 256 OBJECT LOCAL HIDDEN 13 __popcount_tab
> 19143: 0000000000fc4d50 8 FUNC LOCAL HIDDEN 11 _Unwind_GetCFA
> 19144: 00000000014b8820 0 OBJECT LOCAL HIDDEN 17 __DTOR_END__
> 19145: 00000000014b9168 0 OBJECT LOCAL HIDDEN 22 __dso_handle
> 19146: 0000000000fc4e60 269 FUNC LOCAL HIDDEN 11
> __frame_state_for
> 19147: 0000000000fc6760 26 FUNC LOCAL HIDDEN 11
> __register_frame_table
> 19148: 0000000000fc6600 130 FUNC LOCAL HIDDEN 11
> __register_frame_info_bas
> 19149: 0000000000fc6880 5 FUNC LOCAL HIDDEN 11
> __deregister_frame_info
> 19150: 0000000000fc51e0 193 FUNC LOCAL HIDDEN 11 _Unwind_Resume
> 19151: 0000000000fc53b0 26 FUNC LOCAL HIDDEN 11
> _Unwind_DeleteException
> 19152: 0000000000fc6780 256 FUNC LOCAL HIDDEN 11
> __deregister_frame_info_b
> 19153: 0000000000fc4f80 358 FUNC LOCAL HIDDEN 11
> _Unwind_RaiseException
> 19154: 0000000000fc4de0 8 FUNC LOCAL HIDDEN 11 _Unwind_SetIP
> 19155: 0000000000fc66d0 114 FUNC LOCAL HIDDEN 11
> __register_frame_info_tab
> 19156: 0000000000fc6890 33 FUNC LOCAL HIDDEN 11
> __deregister_frame
> 19157: 0000000000fc4e50 8 FUNC LOCAL HIDDEN 11
> _Unwind_GetTextRelBase
> 19158: 0000000000fc4e10 36 FUNC LOCAL HIDDEN 11
> _Unwind_FindEnclosingFunc
> 19159: 0000000000fc4df0 8 FUNC LOCAL HIDDEN 11
> _Unwind_GetLanguageSpecif
> 19160: 0000000000fc50f0 230 FUNC LOCAL HIDDEN 11
> _Unwind_ForcedUnwind
> 19161: 00000000014b8a28 0 OBJECT LOCAL HIDDEN 21
> _GLOBAL_OFFSET_TABLE_
> 19162: 0000000000fc2bf0 44 FUNC LOCAL HIDDEN 11 __popcountdi2
> 19163: 0000000000fc4d60 80 FUNC LOCAL HIDDEN 11 _Unwind_SetGR
> 19164: 0000000000fc4d00 72 FUNC LOCAL HIDDEN 11 _Unwind_GetGR
> 19165: 0000000000fc4e40 8 FUNC LOCAL HIDDEN 11
> _Unwind_GetDataRelBase
> 19166: 0000000000fc6750 9 FUNC LOCAL HIDDEN 11
> __register_frame_info_tab
> 19167: 0000000000fc6690 9 FUNC LOCAL HIDDEN 11
> __register_frame_info
>
>
> The other BSDs consider these symbols global. For example, here is a
> subset of the same symbols taken from a stripped DragonFly BSD gnat1:
>
> 419: 0000000000fb10e0 373 FUNC GLOBAL DEFAULT 10
> _Unwind_Find_FDE
> 582: 0000000000fad8f0 21 FUNC GLOBAL DEFAULT 10
> _Unwind_GetIPInfo
> 920: 0000000000fad8e0 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetIP
> 2116: 0000000000fafb40 235 FUNC GLOBAL DEFAULT 10
> _Unwind_Resume_or_Rethrow
> 2762: 0000000000fad930 8 FUNC GLOBAL DEFAULT 10
> _Unwind_GetRegionStart
> 3171: 0000000000fafc50 155 FUNC GLOBAL DEFAULT 10
> _Unwind_Backtrace
> 4035: 0000000000fad880 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetCFA
> 9786: 0000000000fafa60 212 FUNC GLOBAL DEFAULT 10 _Unwind_Resume
> 9841: 0000000000fafc30 21 FUNC GLOBAL DEFAULT 10
> _Unwind_DeleteException
> 12631: 0000000000faf800 359 FUNC GLOBAL DEFAULT 10
> _Unwind_RaiseException
> 13229: 0000000000fad910 8 FUNC GLOBAL DEFAULT 10 _Unwind_SetIP
> 15888: 0000000000fad980 8 FUNC GLOBAL DEFAULT 10
> _Unwind_GetTextRelBase
> 16508: 0000000000fad940 36 FUNC GLOBAL DEFAULT 10
> _Unwind_FindEnclosingFunc
> 16814: 0000000000fad920 8 FUNC GLOBAL DEFAULT 10
> _Unwind_GetLanguageSpecif
> 17568: 0000000000faf970 230 FUNC GLOBAL DEFAULT 10
> _Unwind_ForcedUnwind
> 18388: 0000000000fad890 75 FUNC GLOBAL DEFAULT 10 _Unwind_SetGR
> 19462: 0000000000fad830 72 FUNC GLOBAL DEFAULT 10 _Unwind_GetGR
> 20086: 0000000000fad970 8 FUNC GLOBAL DEFAULT 10
> _Unwind_GetDataRelBase
> 1345: 0000000000fb0ec0 38 FUNC GLOBAL DEFAULT 10
> __register_frame
> 8011: 0000000000fb0f80 26 FUNC GLOBAL DEFAULT 10
> __register_frame_table
> 8532: 0000000000fb0e20 130 FUNC GLOBAL DEFAULT 10
> __register_frame_info_bas
> 14325: 0000000000fb0ef0 114 FUNC GLOBAL DEFAULT 10
> __register_frame_info_tab
> 20736: 0000000000fb0f70 9 FUNC GLOBAL DEFAULT 10
> __register_frame_info_tab
> 20856: 0000000000fb0eb0 9 FUNC GLOBAL DEFAULT 10
> __register_frame_info
> 9544: 0000000000fb10a0 5 FUNC GLOBAL DEFAULT 10
> __deregister_frame_info
> 10772: 0000000000fb0fa0 256 FUNC GLOBAL DEFAULT 10
> __deregister_frame_info_b
> 15277: 0000000000fb10b0 33 FUNC GLOBAL DEFAULT 10
> __deregister_frame
> 3677: 0000000001284260 256 OBJECT GLOBAL DEFAULT 12 __popcount_tab
> 18046: 0000000000fad460 44 FUNC GLOBAL DEFAULT 10 __popcountdi2
>
>
> I'm pretty well convinced that the NetBSD symbols should also be
> classified as GLOBAL DEFAULT and this explains NetBSD's issue with
> functions such as _Unwind_Resume and _Unwind_GetIPInfo. I've gone
> over config.gcc and the various NetBSD headers many times, but I don't
> see what's causing this or what omission might be causing it.
>
> Can anybody suggest what may be wrong and how to correct it?
>
> Thanks,
> John
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-15 10:56 ` John Marino
@ 2011-01-15 14:25 ` John Marino
2011-01-16 4:01 ` Ian Lance Taylor
1 sibling, 0 replies; 17+ messages in thread
From: John Marino @ 2011-01-15 14:25 UTC (permalink / raw)
To: gcc-help
This wasn't the problem either. NetBSD 5.1 base system has binutils
2.15. I installed binutils 2.17 from pkgsrc and built gcc 4.6 using
options --with-as and --with-ld pointing to the newer assembler and
linker. I confirmed it was using the new linker and assembler, and the
assembler did support .weakref.
But the built gnat1 still shows hidden symbols and still can't build
certain packages because of that. I'm pretty much out of ideas at this
point.
On 1/15/2011 11:56 AM, John Marino wrote:
> I really could use some help on this issue.
> After examining the build logs of both DragonFlyBSD and NetBSD, I
> noticed an interesting difference between the binutils of each system.
>
> DBSD assembler supports .weakref
> NBSD assembler does not.
>
> When reading symbols of env.o (comes from gcc/ada/env.c), there is a
> weak symbol there
> 35: 0000000000000000 8 OBJECT WEAK HIDDEN 20
> DW.ref.__gcc_personality_
>
> unwind-c.c defines PERSONALITY_FUNCTION as __gcc_personality_v0
> libgcc/config/i386/morestack.S mentions the same along with
> DW.ref.__gcc_personality_v0
>
> Could the inability of NetBSD assembler support .weakref be the
> explanation for the unwind symbols to be marked as hidden on the gnat1
> executable even though they are marked as global on their individual
> object files?
>
> Thanks, I'm a bit over my head on this topic.
>
> John
>
>
>
>
> On 1/13/2011 8:12 AM, John Marino wrote:
>> I've successfully built the GNAT front-end of gcc 4.6 on several BSD
>> platforms. The NetBSD versions (i386 and AMD64) have a problem that
>> I can't figure out, and I suspect it can be fixed with a change to
>> the build configuration.
>>
>> Although NetBSD passes its regression tests cleanly, there are some
>> dwarf2 functions it doesn't seem to recognize. When I listed hidden
>> symbols embedded in a pre-stripped gnat1 executable, here is the result:
>>
>> > readelf -s gnat1 | grep HIDDEN
>> 19135: 0000000000fc68c0 389 FUNC LOCAL HIDDEN 11
>> _Unwind_Find_FDE
>> 19136: 0000000000fc4dc0 21 FUNC LOCAL HIDDEN 11
>> _Unwind_GetIPInfo
>> 19137: 0000000000fc4db0 8 FUNC LOCAL HIDDEN 11 _Unwind_GetIP
>> 19138: 0000000000fc66a0 38 FUNC LOCAL HIDDEN 11
>> __register_frame
>> 19139: 0000000000fc52b0 241 FUNC LOCAL HIDDEN 11
>> _Unwind_Resume_or_Rethrow
>> 19140: 0000000000fc4e00 8 FUNC LOCAL HIDDEN 11
>> _Unwind_GetRegionStart
>> 19141: 0000000000fc53d0 155 FUNC LOCAL HIDDEN 11
>> _Unwind_Backtrace
>> 19142: 0000000001299720 256 OBJECT LOCAL HIDDEN 13 __popcount_tab
>> 19143: 0000000000fc4d50 8 FUNC LOCAL HIDDEN 11 _Unwind_GetCFA
>> 19144: 00000000014b8820 0 OBJECT LOCAL HIDDEN 17 __DTOR_END__
>> 19145: 00000000014b9168 0 OBJECT LOCAL HIDDEN 22 __dso_handle
>> 19146: 0000000000fc4e60 269 FUNC LOCAL HIDDEN 11
>> __frame_state_for
>> 19147: 0000000000fc6760 26 FUNC LOCAL HIDDEN 11
>> __register_frame_table
>> 19148: 0000000000fc6600 130 FUNC LOCAL HIDDEN 11
>> __register_frame_info_bas
>> 19149: 0000000000fc6880 5 FUNC LOCAL HIDDEN 11
>> __deregister_frame_info
>> 19150: 0000000000fc51e0 193 FUNC LOCAL HIDDEN 11 _Unwind_Resume
>> 19151: 0000000000fc53b0 26 FUNC LOCAL HIDDEN 11
>> _Unwind_DeleteException
>> 19152: 0000000000fc6780 256 FUNC LOCAL HIDDEN 11
>> __deregister_frame_info_b
>> 19153: 0000000000fc4f80 358 FUNC LOCAL HIDDEN 11
>> _Unwind_RaiseException
>> 19154: 0000000000fc4de0 8 FUNC LOCAL HIDDEN 11 _Unwind_SetIP
>> 19155: 0000000000fc66d0 114 FUNC LOCAL HIDDEN 11
>> __register_frame_info_tab
>> 19156: 0000000000fc6890 33 FUNC LOCAL HIDDEN 11
>> __deregister_frame
>> 19157: 0000000000fc4e50 8 FUNC LOCAL HIDDEN 11
>> _Unwind_GetTextRelBase
>> 19158: 0000000000fc4e10 36 FUNC LOCAL HIDDEN 11
>> _Unwind_FindEnclosingFunc
>> 19159: 0000000000fc4df0 8 FUNC LOCAL HIDDEN 11
>> _Unwind_GetLanguageSpecif
>> 19160: 0000000000fc50f0 230 FUNC LOCAL HIDDEN 11
>> _Unwind_ForcedUnwind
>> 19161: 00000000014b8a28 0 OBJECT LOCAL HIDDEN 21
>> _GLOBAL_OFFSET_TABLE_
>> 19162: 0000000000fc2bf0 44 FUNC LOCAL HIDDEN 11 __popcountdi2
>> 19163: 0000000000fc4d60 80 FUNC LOCAL HIDDEN 11 _Unwind_SetGR
>> 19164: 0000000000fc4d00 72 FUNC LOCAL HIDDEN 11 _Unwind_GetGR
>> 19165: 0000000000fc4e40 8 FUNC LOCAL HIDDEN 11
>> _Unwind_GetDataRelBase
>> 19166: 0000000000fc6750 9 FUNC LOCAL HIDDEN 11
>> __register_frame_info_tab
>> 19167: 0000000000fc6690 9 FUNC LOCAL HIDDEN 11
>> __register_frame_info
>>
>>
>> The other BSDs consider these symbols global. For example, here is a
>> subset of the same symbols taken from a stripped DragonFly BSD gnat1:
>>
>> 419: 0000000000fb10e0 373 FUNC GLOBAL DEFAULT 10
>> _Unwind_Find_FDE
>> 582: 0000000000fad8f0 21 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetIPInfo
>> 920: 0000000000fad8e0 8 FUNC GLOBAL DEFAULT 10 _Unwind_GetIP
>> 2116: 0000000000fafb40 235 FUNC GLOBAL DEFAULT 10
>> _Unwind_Resume_or_Rethrow
>> 2762: 0000000000fad930 8 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetRegionStart
>> 3171: 0000000000fafc50 155 FUNC GLOBAL DEFAULT 10
>> _Unwind_Backtrace
>> 4035: 0000000000fad880 8 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetCFA
>> 9786: 0000000000fafa60 212 FUNC GLOBAL DEFAULT 10
>> _Unwind_Resume
>> 9841: 0000000000fafc30 21 FUNC GLOBAL DEFAULT 10
>> _Unwind_DeleteException
>> 12631: 0000000000faf800 359 FUNC GLOBAL DEFAULT 10
>> _Unwind_RaiseException
>> 13229: 0000000000fad910 8 FUNC GLOBAL DEFAULT 10 _Unwind_SetIP
>> 15888: 0000000000fad980 8 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetTextRelBase
>> 16508: 0000000000fad940 36 FUNC GLOBAL DEFAULT 10
>> _Unwind_FindEnclosingFunc
>> 16814: 0000000000fad920 8 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetLanguageSpecif
>> 17568: 0000000000faf970 230 FUNC GLOBAL DEFAULT 10
>> _Unwind_ForcedUnwind
>> 18388: 0000000000fad890 75 FUNC GLOBAL DEFAULT 10 _Unwind_SetGR
>> 19462: 0000000000fad830 72 FUNC GLOBAL DEFAULT 10 _Unwind_GetGR
>> 20086: 0000000000fad970 8 FUNC GLOBAL DEFAULT 10
>> _Unwind_GetDataRelBase
>> 1345: 0000000000fb0ec0 38 FUNC GLOBAL DEFAULT 10
>> __register_frame
>> 8011: 0000000000fb0f80 26 FUNC GLOBAL DEFAULT 10
>> __register_frame_table
>> 8532: 0000000000fb0e20 130 FUNC GLOBAL DEFAULT 10
>> __register_frame_info_bas
>> 14325: 0000000000fb0ef0 114 FUNC GLOBAL DEFAULT 10
>> __register_frame_info_tab
>> 20736: 0000000000fb0f70 9 FUNC GLOBAL DEFAULT 10
>> __register_frame_info_tab
>> 20856: 0000000000fb0eb0 9 FUNC GLOBAL DEFAULT 10
>> __register_frame_info
>> 9544: 0000000000fb10a0 5 FUNC GLOBAL DEFAULT 10
>> __deregister_frame_info
>> 10772: 0000000000fb0fa0 256 FUNC GLOBAL DEFAULT 10
>> __deregister_frame_info_b
>> 15277: 0000000000fb10b0 33 FUNC GLOBAL DEFAULT 10
>> __deregister_frame
>> 3677: 0000000001284260 256 OBJECT GLOBAL DEFAULT 12
>> __popcount_tab
>> 18046: 0000000000fad460 44 FUNC GLOBAL DEFAULT 10 __popcountdi2
>>
>>
>> I'm pretty well convinced that the NetBSD symbols should also be
>> classified as GLOBAL DEFAULT and this explains NetBSD's issue with
>> functions such as _Unwind_Resume and _Unwind_GetIPInfo. I've gone
>> over config.gcc and the various NetBSD headers many times, but I
>> don't see what's causing this or what omission might be causing it.
>>
>> Can anybody suggest what may be wrong and how to correct it?
>>
>> Thanks,
>> John
>>
>>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-15 10:56 ` John Marino
2011-01-15 14:25 ` John Marino
@ 2011-01-16 4:01 ` Ian Lance Taylor
2011-01-17 19:07 ` John Marino
1 sibling, 1 reply; 17+ messages in thread
From: Ian Lance Taylor @ 2011-01-16 4:01 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
John Marino <gnugcc@marino.st> writes:
> Could the inability of NetBSD assembler support .weakref be the
> explanation for the unwind symbols to be marked as hidden on the gnat1
> executable even though they are marked as global on their individual
> object files?
That a look at the libraries from which the gnat1 executable is pulling
in the symbols, and see how the symbols are marked there. That is, it
is the .so that matters, not the .o. And the .so may be being changed
due to a version script.
Ian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-16 4:01 ` Ian Lance Taylor
@ 2011-01-17 19:07 ` John Marino
2011-01-17 19:29 ` Andrew Haley
2011-01-17 23:35 ` Ian Lance Taylor
0 siblings, 2 replies; 17+ messages in thread
From: John Marino @ 2011-01-17 19:07 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
On 1/16/2011 5:01 AM, Ian Lance Taylor wrote:
> That a look at the libraries from which the gnat1 executable is pulling
> in the symbols, and see how the symbols are marked there. That is, it
> is the .so that matters, not the .o. And the .so may be being changed
> due to a version script.
>
> Ian
Thanks Ian.
I think at least one my issues is the wrong libgcc_s file is getting
linked. It appears the new gcc 4.6 is linking to the NetBSD's system
provided libgcc_s which is from version 4.1 Some symbols such as
_Unwind_GetIPInfo info aren't there.
It may be that the package has an error in it and should be built
statically anyway, but this seems to be a general issue. If the system
libgcc_s is old, yet it's not allowed to replace it with a new version,
what's the best way to deal with that? Would updating the spec
definitions help the newly built gcc pick up the new libgcc_s?
/usr/lib/libgcc_s.so (NetBSD 5.1)
/usr/pkg/lib/libgcc_s.so (pkgsrc version)
Dealing with multiple versions of libgcc_s seems painful....
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-17 19:07 ` John Marino
@ 2011-01-17 19:29 ` Andrew Haley
2011-01-17 19:37 ` MFL Commissioner
2011-01-17 23:35 ` Ian Lance Taylor
1 sibling, 1 reply; 17+ messages in thread
From: Andrew Haley @ 2011-01-17 19:29 UTC (permalink / raw)
To: gcc-help
On 01/17/2011 07:07 PM, John Marino wrote:
> On 1/16/2011 5:01 AM, Ian Lance Taylor wrote:
>> That a look at the libraries from which the gnat1 executable is pulling
>> in the symbols, and see how the symbols are marked there. That is, it
>> is the .so that matters, not the .o. And the .so may be being changed
>> due to a version script.
>
> I think at least one my issues is the wrong libgcc_s file is getting
> linked. It appears the new gcc 4.6 is linking to the NetBSD's system
> provided libgcc_s which is from version 4.1 Some symbols such as
> _Unwind_GetIPInfo info aren't there.
>
> It may be that the package has an error in it and should be built
> statically anyway, but this seems to be a general issue. If the
> system libgcc_s is old, yet it's not allowed to replace it with a
> new version, what's the best way to deal with that?
libgcc_s is supposed to be backwards compatible in all cases, so this
really shouldn't be a problem. Having said that, there may be
incompatibilities in your version.
> /usr/lib/libgcc_s.so (NetBSD 5.1)
> /usr/pkg/lib/libgcc_s.so (pkgsrc version)
>
> Dealing with multiple versions of libgcc_s seems painful....
No more so than any other shared library, I would have thought.
Andrew.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-17 19:29 ` Andrew Haley
@ 2011-01-17 19:37 ` MFL Commissioner
2011-01-17 20:00 ` Andrew Haley
0 siblings, 1 reply; 17+ messages in thread
From: MFL Commissioner @ 2011-01-17 19:37 UTC (permalink / raw)
To: gcc-help
On 1/17/2011 8:29 PM, Andrew Haley wrote:
> libgcc_s is supposed to be backwards compatible in all cases, so this
> really shouldn't be a problem. Having said that, there may be
> incompatibilities in your version.
>
Hi Andrew,
As I understand it, the problem is that the system libgcc (v4.1) isn't
forwards compatible with the newly build compiler (v4.6). The addition
of Unwind_GetIPInfo came about 4 years ago, I guess version 4.1 is older
than that. As long as the object files from the new compiler get
linked with the new libgcc_s, there's no problem, but if they get linked
with an older libgcc_s, then some symbols might not be known.
>> /usr/lib/libgcc_s.so (NetBSD 5.1)
>> /usr/pkg/lib/libgcc_s.so (pkgsrc version)
>>
>> Dealing with multiple versions of libgcc_s seems painful....
>
> No more so than any other shared library, I would have thought.
>
> Andrew.
Well, in additional to the library that comes with the operating system
which can't be removed, there could be multiple versions of gcc on the
same system for any number of reasons. Each may want to build it's own
libgcc_s and perhaps place in the same directory. No, I think libgcc_s
has special challengers over a regular shared library. Unless you mean
port/pkgsrc versions that also compete with a system version, then it
would be a similar problem.
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-17 19:37 ` MFL Commissioner
@ 2011-01-17 20:00 ` Andrew Haley
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Haley @ 2011-01-17 20:00 UTC (permalink / raw)
To: gcc-help
Hi,
On 01/17/2011 07:37 PM, MFL Commissioner wrote:
> On 1/17/2011 8:29 PM, Andrew Haley wrote:
>> libgcc_s is supposed to be backwards compatible in all cases, so this
>> really shouldn't be a problem. Having said that, there may be
>> incompatibilities in your version.
>>
> As I understand it, the problem is that the system libgcc (v4.1)
> isn't forwards compatible with the newly build compiler (v4.6). The
> addition of Unwind_GetIPInfo came about 4 years ago, I guess version
> 4.1 is older than that. As long as the object files from the new
> compiler get linked with the new libgcc_s, there's no problem, but
> if they get linked with an older libgcc_s, then some symbols might
> not be known.
Sure, so you need to put a recent libgcc at the front of your library
path. As long as it really is backwards compatible, all your programs
will still work.
>>> /usr/lib/libgcc_s.so (NetBSD 5.1)
>>> /usr/pkg/lib/libgcc_s.so (pkgsrc version)
>>>
>>> Dealing with multiple versions of libgcc_s seems painful....
>>
>> No more so than any other shared library, I would have thought.
>
> Well, in additional to the library that comes with the operating
> system which can't be removed, there could be multiple versions of
> gcc on the same system for any number of reasons. Each may want to
> build it's own libgcc_s and perhaps place in the same directory.
So, as long as you have the most recent at the head of your path
you'll be fine.
Andrew.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Why are dwarf2 symbols getting assigned hidden visibility?
2011-01-17 19:07 ` John Marino
2011-01-17 19:29 ` Andrew Haley
@ 2011-01-17 23:35 ` Ian Lance Taylor
1 sibling, 0 replies; 17+ messages in thread
From: Ian Lance Taylor @ 2011-01-17 23:35 UTC (permalink / raw)
To: John Marino; +Cc: gcc-help
John Marino <gnugcc@marino.st> writes:
> I think at least one my issues is the wrong libgcc_s file is getting
> linked. It appears the new gcc 4.6 is linking to the NetBSD's system
> provided libgcc_s which is from version 4.1 Some symbols such as
> _Unwind_GetIPInfo info aren't there.
>
> It may be that the package has an error in it and should be built
> statically anyway, but this seems to be a general issue. If the
> system libgcc_s is old, yet it's not allowed to replace it with a new
> version, what's the best way to deal with that? Would updating the
> spec definitions help the newly built gcc pick up the new libgcc_s?
>
> /usr/lib/libgcc_s.so (NetBSD 5.1)
> /usr/pkg/lib/libgcc_s.so (pkgsrc version)
>
> Dealing with multiple versions of libgcc_s seems painful....
libgcc_s is completely backward compatible, so you could safely replace
/usr/lib/libgcc_s.so with your newer version. That said, I think you
are basically asking a packaging question, rather than a gcc question.
At link time, gcc should find the one you just built. At runtime, the
one that is used is up to the dynamic linker. One way you could control
the dynamic linker would be to arrange for gcc to pass an appropriate
-rpath option to the linker. Whether that is a good idea depends
entirely on how your system should run.
Ian
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-01-17 23:35 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-13 7:12 Why are dwarf2 symbols getting assigned hidden visibility? John Marino
2011-01-13 8:32 ` Jonathan Wakely
2011-01-13 10:28 ` John Marino
2011-01-13 12:45 ` Jonathan Wakely
2011-01-13 16:47 ` John Marino
2011-01-13 16:55 ` Jonathan Wakely
2011-01-13 19:32 ` John Marino
[not found] ` <4D2F5250.8020200@marino.st>
2011-01-13 19:41 ` Jonathan Wakely
2011-01-14 1:03 ` John Marino
2011-01-15 10:56 ` John Marino
2011-01-15 14:25 ` John Marino
2011-01-16 4:01 ` Ian Lance Taylor
2011-01-17 19:07 ` John Marino
2011-01-17 19:29 ` Andrew Haley
2011-01-17 19:37 ` MFL Commissioner
2011-01-17 20:00 ` Andrew Haley
2011-01-17 23:35 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).