I think that means things are dynamically relocated and it's basically impossible to associate running code with a binary file and/or source? That's unfortunate :-/.
Gabe On 10/25/11 05:24, Ali Saidi wrote: > It's not a file, it's a bunch of objects in a directory hierarchy. Think > kernel modules for nearly everything. > > Ali > > Sent from my ARM powered mobile device > > On Oct 25, 2011, at 5:04 AM, Gabe Black <[email protected]> wrote: > >> Do you know where the solaris kernel actually is on that disk image? I >> can't disassemble it if I don't know which file it is :-P. Ali? >> >> Gabe >> >> On 10/25/11 02:30, Gabe Black wrote: >>> Ah, ok, I was just being dumb. All the stdf-s and lddf-s are just moving >>> memory around, I think. That way you can load/store 64 bits at a time >>> and get it done with fewer instructions. I think those instructions >>> themselves can be ignored. I'm also surprised that there would be much >>> floating point. >>> >>> I'm currently building binutils for SPARC, so hopefully I can >>> disassemble some things and get a better idea of what's going on. It's >>> probably going to be really annoying to figure it out. >>> >>> Gabe >>> >>> On 10/25/11 00:32, Steve Reinhardt wrote: >>>> Hard to tell... there are larger and larger differences after that point >>>> that seem to be cascading from this one, but it takes a while before they >>>> diverge completely. I put the trace in /tmp/tracediff-8625.out on zizzer >>>> if >>>> you want to take a look for yourself. >>>> >>>> It seems odd that the solaris boot would be doing that much FP in any case, >>>> but there does seem to be quite a bit of it. >>>> >>>> Steve >>>> >>>> >>>> On Tue, Oct 25, 2011 at 12:17 AM, Gabe Black <[email protected]> wrote: >>>> >>>>> An FP rounding error seems very plausible, but I'm not sure how +/- zero >>>>> would make any difference. I'm skeptical that our FP implementation in >>>>> SPARC is accurate enough to care much about such a small difference, >>>>> although it is, of course, entirely possible it cascades from there into >>>>> a larger difference which breaks things. >>>>> >>>>> I've gone back and improved the SPARC disassembly in the past, but it's >>>>> still not perfect. The problem is the hierarchy that works for getting >>>>> instructions to work doesn't necessarily mirror the one you need to get >>>>> accurate disassembly. I think I went with operand position too (src 0 is >>>>> for this, dest 0 is for that) and that doesn't always work very well. >>>>> That's probably what's going wrong here. >>>>> >>>>> Is there a point after this where things diverge significantly? This >>>>> could be just a blip of noise and the real problem happens a lot later. >>>>> It's a *major* pain in the butt to write code that theoretically handles >>>>> all the little FP weird cases and gets all the bits right when the host >>>>> ISA has different rules for FP than the guiest, and it's even harder to >>>>> actually get the compiler to generate that code without moving things >>>>> around and messing it all up. And glibc's FP support is wrong sometimes! >>>>> What fun. I largely think it's farther on, and also partially am holding >>>>> out hope we don't have to wade into FP soup. >>>>> >>>>> Gabe >>>>> >>>>> On 10/24/11 09:19, Steve Reinhardt wrote: >>>>>> Great, thanks a lot. I was able to build with >>>>>> 'CC=/usr/bin/gcc-4.4 CXX=/usr/bin/g++-4.4' and get a binary that passes >>>>> this >>>>>> test on the head, so it's definitely the compiler. I also ran tracediff >>>>> and >>>>>> it looks like it's an off-by-one thing with %fp; here's the first error: >>>>>> >>>>>> -931697720: system.cpu T0 : 0xff1aa5b8 : stdf %fp, [%f29 + >>>>> -0x20] : >>>>>> MemWrite : D=0x423000000000197a A=0xfeffa280 >>>>>> +931697720: system.cpu T0 : 0xff1aa5b8 : stdf %fp, [%f29 + >>>>> -0x20] : >>>>>> MemWrite : D=0x4230000000001979 A=0xfeffa280 >>>>>> >>>>>> (The good gcc-4.4 version is second, so the '1979' is the correct value >>>>>> here.) >>>>>> >>>>>> I ran one more tracediff with '--debug-flag=All --trace-start=931600000' >>>>> to >>>>>> see if anything else turns up sooner, and got this: >>>>>> >>>>>> @@ -1380553 +1380553 @@ >>>>>> 931697014: system.cpu.[tid:0]: Reading float reg 3 (3) bits as 0, 0. >>>>>> 931697014: system.cpu.[tid:0]: Reading float reg 2 (2) bits as >>>>> 0x3e300000, >>>>>> 0.171875. >>>>>> 931697014: global: FSR read as: 0xc0000000 >>>>>> -931697014: system.cpu.[tid:0]: Setting float reg 12 (12) bits to 0, 0. >>>>>> +931697014: system.cpu.[tid:0]: Setting float reg 12 (12) bits to >>>>>> 0x80000000, -0. >>>>>> 931697014: system.cpu.[tid:0]: Setting float reg 13 (13) bits to 0, 0. >>>>>> 931697014: global: FSR written with: 0xc0000000 >>>>>> 931697014: system.cpu + A16 T0 : 0xff1aa434 : fsubd >>>>>> %f31,%f30,%f12 : FloatAdd : D=0x00000000c0000000 >>>>>> @@ -1380951 +1380951 @@ >>>>>> 931697038: system.cpu.[tid:0]: Reading float reg 5 (5) bits as 0, 0. >>>>>> 931697038: system.cpu.[tid:0]: Reading float reg 4 (4) bits as 0, 0. >>>>>> 931697038: system.cpu.[tid:0]: Reading float reg 13 (13) bits as 0, 0. >>>>>> -931697038: system.cpu.[tid:0]: Reading float reg 12 (12) bits as 0, 0. >>>>>> +931697038: system.cpu.[tid:0]: Reading float reg 12 (12) bits as >>>>>> 0x80000000, -0. >>>>>> 931697038: global: FSR read as: 0xc0000000 >>>>>> 931697038: system.cpu.[tid:0]: Setting float reg 18 (18) bits to 0, 0. >>>>>> 931697038: system.cpu.[tid:0]: Setting float reg 19 (19) bits to 0, 0. >>>>>> @@ -1381022 +1381022 @@ >>>>>> 931697042: system.cpu.[tid:0]: Reading float reg 10 (10) bits as >>>>>> 0x41300000, 11. >>>>>> 931697042: global: FSR read as: 0xc0000000 >>>>>> 931697042: system.cpu.[tid:0]: Setting float reg 16 (16) bits to >>>>>> 0x41300000, 11. >>>>>> -931697042: system.cpu.[tid:0]: Setting float reg 17 (17) bits to 0xe685, >>>>>> 8.26948e-41. >>>>>> +931697042: system.cpu.[tid:0]: Setting float reg 17 (17) bits to 0xe684, >>>>>> 8.26934e-41. >>>>>> 931697042: global: FSR written with: 0xc0000000 >>>>>> 931697042: system.cpu + A16 T0 : 0xff1aa4a4 : faddd >>>>> %f3,%f2,%f16 >>>>>> : FloatAdd : D=0x00000000c0000000 >>>>>> 931697042: Event_18: AtomicSimpleCPU tick event scheduled @ 931697043 >>>>>> >>>>>> Could it be some kind of FP rounding error? It's not clear how that >>>>> would >>>>>> end up affecting %fp though. (Actually, looking at this a little closer, >>>>>> are we even disassembling that correctly? Seems to me it should be 'stdf >>>>>> %f29, [%fp + -0x20]'.) >>>>>> >>>>>> I won't have time to look into this further anytime soon, but I hope this >>>>>> will give someone else (Gabe?) enough to go on to get this figured out. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On Sun, Oct 23, 2011 at 7:50 PM, Ali Saidi <[email protected]> wrote: >>>>>> >>>>>>> I've installed it. >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> On Oct 23, 2011, at 7:18 PM, Steve Reinhardt wrote: >>>>>>> >>>>>>>> This makes sense, since the time the regression started failing is >>>>>>>> consistent with when gcc was upgraded on zizzer. >>>>>>>> >>>>>>>> I see there is a gcc-4.4 package available for ubuntu 11.04 (which >>>>> zizzer >>>>>>> is >>>>>>>> running)... is there more to it than installing that package and >>>>>>> recompiling >>>>>>>> to get a workable binary to run tracediff with? >>>>>>>> >>>>>>>> I'd try myself but I've forgotten my zizzer password (again!) so I >>>>> can't >>>>>>>> sudo. It's tough when you've had the same password for ten years then >>>>>>> you >>>>>>>> change it but don't use the new one much... >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On Sun, Sep 25, 2011 at 1:14 PM, Ali Saidi <[email protected]> wrote: >>>>>>>> >>>>>>>>> Yes.. What Gabe said. With gcc 4.5 (version zizzer now runs) I cannot >>>>>>> find >>>>>>>>> a version of the repository that passes sparc boot. I'm pretty sure >>>>>>> it's an >>>>>>>>> annoying compiler issue, but there are some annoyances is figuring out >>>>>>> where >>>>>>>>> to look at Gabe points out. If you're stats changes work on everything >>>>>>> else, >>>>>>>>> I'm happy to see them committed while this issue goes on in the >>>>>>> background. >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Ali >>>>>>>>> >>>>>>>>> Sent from my ARM powered device >>>>>>>>> >>>>>>>>> On Sep 25, 2011, at 3:06 PM, Gabe Black <[email protected]> >>>>> wrote: >>>>>>>>>> We (Ali and I) have each looked at that before, and we think it >>>>> depends >>>>>>>>>> on the compiler version. Something changes when you have a new enough >>>>>>>>>> gcc and then the behavior of SPARC changes. I think the new behavior >>>>> is >>>>>>>>>> broken and the old behavior is correct, but I'd have to look at it >>>>>>>>>> again. I haven't looked into it farther than that yet because I'd >>>>> want >>>>>>>>>> to tracediff between versions built with different compilers. Since >>>>>>> they >>>>>>>>>> would need to find different versions of libraries and can't just run >>>>>>>>>> from the same command line, it's logistically annoying. >>>>>>>>>> >>>>>>>>>> Gabe >>>>>>>>>> >>>>>>>>>> On 09/25/11 09:52, nathan binkert wrote: >>>>>>>>>>> I'm trying to get my python stats changes into the tree, but it >>>>>>>>>>> appears that one of the regression tests no longer works (zizzer >>>>>>>>>>> agrees with me): >>>>>>>>>>> >>>>>>>>>>> >>>>> SPARC_FS/tests/opt/long/80.solaris-boot/sparc/solaris/t1000-simple-atomic >>>>>>>>>>> Gabe, I think you're the only one that's been messing with SPARC. >>>>> Can >>>>>>>>>>> you take a look? >>>>>>>>>>> >>>>>>>>>>> Nate >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> gem5-dev mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>>>>>> _______________________________________________ >>>>>>>>>> gem5-dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> gem5-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> gem5-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-dev mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> gem5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>> _______________________________________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>> >>>> _______________________________________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/gem5-dev >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
