Re: segfault using __thread variable
On 12 December 2013 23:14, Michael Hudson-Doyle wrote: > Will Newton writes: > >> On 12 December 2013 21:59, Michael Hudson-Doyle >> wrote: >>> Will Newton writes: > > [snp] > I would guess that 0x64c000 is the base of the GOT and 776 is the offset into it (but I could be wrong). objdump -h will give you the layout of the sections, objdump -R will dump the relocations. >>> >>> So I get this: >>> >>> $ objdump -h build/linux2/normal/mongo/base/counter_test | grep got >>> --context=2 >>> 23 .dynamic 0220 0064b160 0064b160 0023b160 >>> 2**3 >>> CONTENTS, ALLOC, LOAD, DATA >>> 24 .got 1c78 0064b380 0064b380 0023b380 >>> 2**3 >>> CONTENTS, ALLOC, LOAD, DATA >>> 25 .data 0130 0064d000 0064d000 0023d000 >>> 2**4 >>> >>> And objdump -C -R gives this: http://paste.ubuntu.com/6563640/ >>> >>> This would seem to be the relevant entry: >>> >>> 0064ccb8 R_AARCH64_TLS_TPREL64 mongo::_threadOstreamCache >>> >>> But I don't know what the offset means here and how it relates to the >>> 776 in "ldr x0, [x0,#776]". 0x64c000 + 776 is 0x64c308 which is >>> >>> 0064c308 R_AARCH64_GLOB_DAT vtable for >>> boost::program_options::typed_value >> >> This looks wrong. > > Yeah, it does. Also poking around at 0x64c308 shows something that > looks very much like a vtable for a class called typed_value... > >>> which is just random, but I don't know if that's a valid thing to be >>> looking at :-) That said, if we examine the memory at 0x64ccb8 and >>> interpret it as an offset against tpidr_el0 things *seem* to make sense: >>> >>> (gdb) x 0x64ccb8 >>> 0x64ccb8: 0x0010 >>> (gdb) x/g $x1 + 0x10 >>> 0x7fb7ff7700: 0x >>> >>> The correct value for this tls pointer at this point in time _is_ in >>> fact NULL, but obviously this could happen just by chance :-) >>> >>> Still, looks a bit like a toolchain bug to me. This is with g++ 4.8 >>> from trusty fwiw. >> >> I would be inclined to agree. Is there a simple way to reproduce the build? > > Ha. No, I've only seen this when compiling all of mongodb, which takes > a pretty long time on hw. I'll certainly let you know if I can come up > with something smaller. I'll also try with 4.9. Small is good, but we do have access to hardware so at least it won't be days waiting for the model. ;-) >> (although I don't think I will have time to look at it until the new year) > > No worries, a bug on launchpad.net/linaro-gcc is the right way to track > this properly? Yeah I think so, although I think it will actually be a binutils bug. -- Will Newton Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: segfault using __thread variable
Will Newton writes: > On 12 December 2013 23:14, Michael Hudson-Doyle > wrote: >> Will Newton writes: >> >>> On 12 December 2013 21:59, Michael Hudson-Doyle >>> wrote: Will Newton writes: >> >> [snp] >> > I would guess that 0x64c000 is the base of the GOT and 776 is the > offset into it (but I could be wrong). objdump -h will give you the > layout of the sections, objdump -R will dump the relocations. So I get this: $ objdump -h build/linux2/normal/mongo/base/counter_test | grep got --context=2 23 .dynamic 0220 0064b160 0064b160 0023b160 2**3 CONTENTS, ALLOC, LOAD, DATA 24 .got 1c78 0064b380 0064b380 0023b380 2**3 CONTENTS, ALLOC, LOAD, DATA 25 .data 0130 0064d000 0064d000 0023d000 2**4 And objdump -C -R gives this: http://paste.ubuntu.com/6563640/ This would seem to be the relevant entry: 0064ccb8 R_AARCH64_TLS_TPREL64 mongo::_threadOstreamCache But I don't know what the offset means here and how it relates to the 776 in "ldr x0, [x0,#776]". 0x64c000 + 776 is 0x64c308 which is 0064c308 R_AARCH64_GLOB_DAT vtable for boost::program_options::typed_value >>> >>> This looks wrong. >> >> Yeah, it does. Also poking around at 0x64c308 shows something that >> looks very much like a vtable for a class called typed_value... >> which is just random, but I don't know if that's a valid thing to be looking at :-) That said, if we examine the memory at 0x64ccb8 and interpret it as an offset against tpidr_el0 things *seem* to make sense: (gdb) x 0x64ccb8 0x64ccb8: 0x0010 (gdb) x/g $x1 + 0x10 0x7fb7ff7700: 0x The correct value for this tls pointer at this point in time _is_ in fact NULL, but obviously this could happen just by chance :-) Still, looks a bit like a toolchain bug to me. This is with g++ 4.8 from trusty fwiw. >>> >>> I would be inclined to agree. Is there a simple way to reproduce the build? >> >> Ha. No, I've only seen this when compiling all of mongodb, which takes >> a pretty long time on hw. I'll certainly let you know if I can come up >> with something smaller. I'll also try with 4.9. > > Small is good, but we do have access to hardware so at least it won't > be days waiting for the model. ;-) > >>> (although I don't think I will have time to look at it until the new year) >> >> No worries, a bug on launchpad.net/linaro-gcc is the right way to track >> this properly? > > Yeah I think so, although I think it will actually be a binutils bug. Aaah, you might be onto something there. I built myself a cross gcc-4.8 today and it appeared to compile things correctly (I didn't actually get to run it, but the objdump poking looked right) and I got a bit worried that this was all down to some cosmic ray / corruption when I first compiled it. But, the scripts I cargo culted just use compile binutils from git tip, so if the bug is in binutils... Cheers, mwh ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week 50
== Progress == * Bugfixing and testing QEMU AArch64 FP patches (7/10, VIRT-183) * Debugging and submitting a patch for issue with Ruby and ARM pointer encryption (2/10) * Other miscellaneous work: glibc patch review, binutils testsuite patch, expenses (1/10) == Issues == * None == Plan == * 2 day week next week then off until Jan 8th * Wrap up qemu work to a good state to handover -- Will Newton Toolchain Working Group, Linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week 50
== Progress == * Pragma Vectorize - Comparing pragma OMP to mimic for vectorize - Implementing the lexer/parser - http://llvm.org/PR18086 * Android LLVM - Wasting time for the last time with Odroid XU and Android - Will focus on Nexus 4, 5 and 7 * Integrated AS - Changed to enabled by default - Discussing some bugs found on Android unwind library (inline asm) - http://llvm.org/PR18231 * Release 3.4 - There were some muddled merges, folks are trying to fix - Bero found a serious bug, seems to be result of the bad merge - http://llvm.org/PR18201 - Tested RC2, waiting for RC3 * Background - Discussions, lots of patch reviews * Time - CARD-862 8/10 - Others 2/10 == Plan == * Continue implementing pragma vectorize in Clang * Wait for the next release candidate, test, benchmark * Follow up in the IAS issues raised * If RemoteChild is gone by then, continue the MCJIT refactoring * Have a look at TableGen users == Issues == I saw a black cat, under a ladder, with a hockey mask... ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[Weekly] 09-13 DEC 2013
== This week == - Completed backport of 202259, 202407, 202020, 201261 and 201263 - Submitted merge requesSt for completed backports == Next week == - Begin work on other assigned backports == Future == Document missing features of cbuild for backports ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week 50 (Dec 9 - Dec 13)
== Progress == (4/10)
* TCWG-372 fix Cbuildv2 parsing to handle the new binutils-gdb repository (4/10)
- Completed Card with following commits.
commit e6e39f5d1f7963332b3d7dd2e4400de91847219c
Author: Ryan S. Arnold
Date: Tue Dec 10 16:08:17 2013 -0600
Correct get_toolname to work with unified repo: binutils-gdb.git
Secondary fixes required:
- Set config/binutils.conf and config/gdb.conf to use unified repo
binutils-gdb.git.
- Re-enable binutils-gdb.git in config/sources.conf.
- get_toolname now calls get_git_tool and determines the actual toolname
for binutils and gdb from the branch name if the repository is unified.
- Made all other usages of get_git_tool use get_toolname instead.
- checkout() now uses ${repo} as returned from get_git_repo as the git
repository instead of ${tool}.git. This allows a unified repository to
only be checked out once.
- The git parser now determines whether an http:// in a url means a git
service or an svn service.
- The git parser now returns branch names for launchpad urls with branches
in the url.
- The git parser now returns the tool name properly for an svn service.
- The git parser testsuite now has testcases for all new additions.
Also
- Added --snapshots functionality to allow specifying an existing snapshots
directory.
- Add testcases to test.sh to test --snapshots functionality.
- Changes test.sh --snapshots directive to --md5sums to avoid confusion
with cbuild2.sh --snapshots.
* TCWG-323 Interface hardening (5/10)
- Card in progress with following commits:
commit cc7193d8ddb86c4ed7d16086f8ee968ae4bae87f
Author: Ryan S. Arnold
Date: Thu Dec 12 11:40:00 2013 -0600
cbuild2.sh: All error exit paths should use build_failure().
commit 2a4ec7fa0b7c48e0c6e05a7549f64e3336022f45
Author: Ryan S. Arnold
Date: Wed Dec 11 14:08:51 2013 -0600
cbuild2.sh: Added check_directive() to unify bounds checking.
Also added accompanying top-level test.sh fragments to test
check_directive.
Change-Id: Ia42a4b241a5ca62d41dccf1d8e023980ad0a04d0
commit c9ec21200260bdb26d9fe9b26d7ce390579a0ca2
Author: Ryan S. Arnold
Date: Wed Dec 11 13:07:15 2013 -0600
test.sh: Fixed to work with a temporary host.conf file.
Require change due to commit 3b5c576630a8ac08cd3b9ab9eab781308549a858
which requires a host.conf file for finding the cbuild topdir.
Change-Id: I991bb5f2a7949267bf69fba093d6becd202ad138
commit 16a45027be798b06160916234713f5dc35b2ecbb
Author: Ryan S. Arnold
Date: Tue Dec 10 18:16:09 2013 -0600
cbuild2.sh: Bounds check --set input.
Change-Id: I8ebffd1809b17962aef58f2a08277d5f639d7e3e
commit d7ee602c24231e24457c93208f749cbdd0357115
Author: Ryan S. Arnold
Date: Tue Dec 10 18:03:04 2013 -0600
cbuild2.sh: Remove --srcdir. It didn't do anything.
Change-Id: I5b99c7ae8dc542cb62516104bd0bf9d1888afc52
commit 53e9c74966442c41cc9512f27f46ef849d62bcc8
Author: Ryan S. Arnold
Date: Tue Dec 10 17:58:54 2013 -0600
cbuild2.sh: Remove --dispatch support. It didn't do anything.
commit 289ade38f100872653218da4792fbb1650d3b231
Author: Ryan S. Arnold
Date: Wed Dec 11 10:27:37 2013 -0600
cbuild2.sh: Bounds check --release switch.
Change-Id: I90804ea02b995d476b148fb68db955d164bc674c
commit 9bae259ebbff193e29899edf8a47190747d2bc1b
Author: Ryan S. Arnold
Date: Wed Dec 11 10:09:00 2013 -0600
lib/configure.sh: Add missing closing "
Change-Id: I9eee9a934a6cbb60bd1e2db6b0af9faf19fa5188
commit 16a45027be798b06160916234713f5dc35b2ecbb
Author: Ryan S. Arnold
Date: Tue Dec 10 18:16:09 2013 -0600
cbuild2.sh: Bounds check --set input.
Change-Id: I8ebffd1809b17962aef58f2a08277d5f639d7e3e
commit d7ee602c24231e24457c93208f749cbdd0357115
Author: Ryan S. Arnold
Date: Tue Dec 10 18:03:04 2013 -0600
cbuild2.sh: Remove --srcdir. It didn't do anything.
Change-Id: I5b99c7ae8dc542cb62516104bd0bf9d1888afc52
commit 53e9c74966442c41cc9512f27f46ef849d62bcc8
Author: Ryan S. Arnold
Date: Tue Dec 10 17:58:54 2013 -0600
cbuild2.sh: Remove --dispatch support. It didn't do anything.
Change-Id: I4b6ee8db0d3e74510b95c816469b0c100207972f
* Misc (1/10)
- Now using gerrit with git review for handling cbuildv2 development.
- Reviewed V Chong's proposed outline for toolchain documentation and
made suggestions and edits.
== Plan ==
* Move onto working primarily on glibc Jira cards.
== Issues ==
* Lab migration took cbuild.validation.linaro.org down for several
unplanned days and therefore toolchain sources were unavailable during
that time. I made do by adding some features into cbuildv2 to use
alternative snapshots directories.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
