T2 IRC Log: 2010-10-18

This is the log as captured by an IRC bot in the channel. The statements are those of the individual people and might not neccessarily reflect the policy and legal rules as set forth by the T2 SDE Project.

« prev | next »

--- Log opened Mon Oct 18 00:00:58 2010
00:37 -!- sajack [~khezef@rrdhcp144-122.redrover.cornell.edu] has quit [Ping timeout: 240 seconds]
02:52 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has joined #t2
04:57 -!- cb88 [~cb88@244.charlotte-04rh15-16rt.nc.dial-access.att.net] has joined #t2
05:35 < cb88> been trying to build sparc32 not getting very far though... there do seem to be some incorrect options passed to the gcc configure
05:41 < cb88> or I'm probably mising something ... ;-)
06:12 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has quit [Ping timeout: 250 seconds]
07:06 -!- cb88 [~cb88@244.charlotte-04rh15-16rt.nc.dial-access.att.net] has quit [Ping timeout: 252 seconds]
07:07 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has joined #t2
09:04 -!- sajack [~khezef@rrdhcp146-285.redrover.cornell.edu] has quit [Ping timeout: 272 seconds]
10:40 -!- mjungwirth [~mjungwirt@213.174.234.68] has quit [Quit: Nettalk6 - www.ntalk.de]
10:43 -!- mjungwirth [~mjungwirt@213.174.234.68] has joined #t2
12:30 < rogermason> hello.
12:35 < rogermason> rxr: regarding root, it _is_ rootcint_tmp that fails:Program received signal SIGSEGV, Segmentation fault.
12:35 < rogermason> 0x00000000101b6a3c in .G__tovalue ()
12:37 < rogermason> gdb does not identify the file or line, but G__tovalue() is defined in cint/cint/src/value.cxx, which (I think) contains some assembler macros.
12:43 < rxr> there is no PPC assembly, though
12:45 < CIA-27> rene * r37842 /trunk/package/network/bluez/bluez.desc: * updated bluez (4.75 -> 4.76)
12:49 < rxr> you do use root actively?
12:49 < rxr> have you continued to chat with the root dev's about this?
12:54 < rogermason> yes, I use root almost exclusively for data processing. I have not had further discussuion with the root devs after their statement about not supporting 64 bit compilation on ppc.
13:06 < rxr> well, I do not know much about root
13:07 < rxr> the developers may (should) se some offender at a glance, ...
13:07 < rxr> Program received signal SIGSEGV, Segmentation fault.
13:07 < rxr> G__tovalue (p=...) at cint/cint/src/value.cxx:413
13:07 < rxr> 413 result.obj.in = (*(int *)(p.obj.i));
13:07 < rxr> (gdb) p result
13:07 < rxr> $1 =
13:07 < rxr> (gdb) p p
13:07 < rxr> $2 = {obj = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 '\000', sh = 0, in = 0, fl = 0, uch = 0 '\000', ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = 0},
13:07 < rxr> ref = 0, type = 73, tagnum = -1, typenum = -1, isconst = 0 '\000', dummyForCint7 = {fTypeName = 0x0, fModifiers = 0}}
13:07 < rxr> (gdb) p p.obj
13:07 < rxr> $3 = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 '\000', sh = 0, in = 0, fl = 0, uch = 0 '\000', ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = 0}
13:07 < rxr> (gdb) p p.obj.i
13:07 < rxr> $4 = 0
13:10 < rogermason> rxr: thank you. I will pass this back to them. How did tou get gdb to give you a line number?
13:11 < rxr> I run the line from the log in gdb
13:11 < rxr> gdb core/utils/src/rootcint_tmp
13:11 < rxr> r -cint -f ... ...
13:11 < rxr> r for "ruN"
13:13 < rogermason> OK. I used gdb --args core/utils/src/rootcint_tmp -cint -f ...
13:14 < rogermason> then run. That did not specify where the segfault happened.
13:14 < rxr> oh
13:14 < rxr> I switch on the CONFIG_DEBUG in the t2 config so that all binaries are built with debug symbols :-)
13:16 < rogermason> Ah. Yes, gdb told me that there were no debug symbols. Silly me. I'll do likewise.
13:28 < rxr> :-)
13:28 < rxr> lunch
14:34 < rxr> cu
14:34 < rxr> err re
15:04 < rogermason> This is what the root guys have to say: yes, I know *why* it's failing. That's precisely the reason why we can
15:04 < rogermason> clearly state: not supported :-) CINT has an assumption on endianess,
15:04 < rogermason> and works around it for 32 bit by using int and long as interchangeable
15:04 < rogermason> types. On 64 bit that's not the case, and CINT uses the "wrong part" of
15:04 < rogermason> the byte group. Changing that would be major surgery that we much prefer
15:04 < rogermason> investing in replacing CINT altogether.
15:06 < rxr> don't see how they work around endianess issues with long and int, ..
15:10 < rogermason> Me neither. I did once write some byte-swapping code, but it is so long ago that I don't even remember why it was needed.
15:12 < rogermason> I know that CINT (a C/C++ interpreter is going to be replaced at some point by something (CLING? CLANG) derived from llvm, so I understand their point of view.
15:23 < rxr> well the byte swapping is trivial
15:24 < rxr> I even have my own C++ templates in my projects that do so automatically based on specified in-memory order, like native, big- or little-endian
15:25 < rxr> the only way I can imageine right now is that they add some template glue and miss-use the long type to have some conversion function match those assignments, ...
15:25 < rxr> the question is how pervasive their use is, if that is the only thing root is missing on ppc64 then we may even able to patch it up
15:25 < rxr> if the next, other issue is just lingering ahead then it may not worth to even look at it, ..
15:26 < rxr> and just build 32bit userland for your root use, ..
15:32 < rogermason> I get the sense from the devs that no help will be forthcoming, so patching may not be the best option.
17:21 -!- mqueiros_ [~mqueiros@a83-132-0-130.cpe.netcabo.pt] has quit [Quit: Ex-Chat]
21:53 -!- old_gaffer [~quassel@211.238.240.87] has quit [Quit: No Ping reply in 180 seconds.]
21:59 -!- gluemonkey [~gluemonke@67.137.235.168] has joined #t2
--- Log closed Tue Oct 19 00:00:58 2010