IRC logs for #openrisc Wednesday, 2016-05-11

--- Log opened Wed May 11 00:00:01 2016
olofkshorne: Looks to me like the failing tests in structs are also caused by the "reg not updated" warnings01:16
olofkAll the more reason to find a kill that01:17
olofkAny clue where they might come from?01:17
olofkMaybe here?
olofkOr more likeley, line 534 in the same function01:20
olofk_franck_: Any clues?01:21
olofkIs this only in the sim backend, or does debugging against or1ksim or hw yield the same warning?01:22
olofkshorne: Did you ever upload the commands to run the testsuite? I couldn't see anything when I skimmed through the backlog01:26
_franck__olofk: no I don't.02:41
_franck__as for running the testsuite:
_franck__and you can run only on test using an option. Which one ? :)02:41
_franck__make check RUNTESTFLAGS="testfilename.exp"02:50
olofkHow do I only build gdb?03:12
_franck__I would try to go in gdb subdir then ./configure --target=or1k-elf --disable-tk --disable-tcl03:17
olofkAh. That's worth a try03:17
olofkI did a full stage 2 build out-of-tree instead. Hopefully that doesn't take too long03:18
olofkHmm.. where should we put this "boards" directory?03:23
olofkoh.. I need dejagnu too I guess03:26
olofkNot there yet :(03:33
olofkWARNING: Couldn't find the global config file.03:33
olofkWARNING: No tool specified03:33
_franck__olofk: did you get those files:
olofk_franck_: Yep.03:37
olofkoh.. not site.exp03:37
olofkAnd I need to set a DEJAGNU env var to something...?03:40
olofkWhere should I put site.exp? in $build_gdb/gdb/testsuite ?03:45
olofkStill get warnings :/03:46
olofkAccording to jeremybennett's app note, DEJAGNU env var should be set to something to avoid warnings, but what???03:47
olofkI give up03:57
_franck__olofk: export DEJAGNU=~/site.exp04:11
shorneolofk: Don't Panic!05:14
shorneI uploaded other instructions here too:
shorneat the top of the gdb.log05:15
shornebasically I do05:15
shorne1. clone or1k-src from github05:15
shorne2. export DEJAGNU={gitroot}/or1k-src/site.exp05:16
shorne(to build gdb, I just build the whole thing, with make -j9) it takes about 2 minutes05:17
shorne(build whole thing means05:17
shorne1. clone binutils-gdb05:17
shorne2. mkdir build-gdb # alongside the binutils-gdb directory05:18
shornethen ../binutils-gdb/configure ... (as per my link above)05:18
shornewhen done, (and still in the build-gdb directory) cd gdb, and run 'make check ...'05:19
shorneyou can do single test like "make check RUNTESTFLAGS="--target_board=or1k-elf-sim gdb.base/structs.exp""05:20
shorneIn terms of the failure for structs, I agree, it looks like gdb is scanning for some output but stumbling on those warnings.  I think I can fix them.05:21
shornethe warning comes from calling this method (I think we didnt have this issue in or1ksim)
shorneThis is where I just implemented for PC and General registers to get things going05:26
shorneeasy to add implementation for SR and PPC05:26
olofkhi shorne. I'll try some more later today06:25
shorneit should be easy to add implementation for SR and PPC07:11
olofkshorne: I didn't follow the instructions exactly, but I think it should be close enough. Problem is that it still complains that it can't find some tool (?)07:33
olofkWARNING: No tool specified07:33
olofkWARNING: Couldn't find tool config file for unix, using default.07:33
olofkhmmm... could it be that it's looking for or1k-elf-gdb?07:38
olofkBecause I don't have that anywhere07:38
olofkRebuilding the whole thing. Let's see if that works07:52
olofkwoohoo! It's runining now07:59
olofkrunning, not ruining :)08:02
shorneI fixed those warnings but still getting a few failures in the  structs.exp test08:47
olofkshorne: Nice. Did the overall number of failed tests decrease?08:52
shorneFor structs test it went from 106 -> 24 failures08:58
olofkshorne: This fixes a fail in bp_permanent08:58
shornerunning overall now08:58
olofkdiff --git a/gdb/testsuite/gdb.base/bp-permanent.c b/gdb/testsuite/gdb.base/bp-permanent.c08:58
olofkindex 541a89b..7e17dc7 10064408:58
olofk--- a/gdb/testsuite/gdb.base/bp-permanent.c08:58
olofk+++ b/gdb/testsuite/gdb.base/bp-permanent.c08:58
olofk@@ -26,6 +26,8 @@08:58
olofk#if defined(__s390__) || defined(__s390x__) #define NOP asm("nopr 0")08:58
olofk+#elif defined(__or1k__)08:58
olofk+#define NOP asm("l.nop") #else #define NOP asm("nop") #endif08:58
olofkNote to self. Don't paste many lines :)08:59
shorneits ok, doesnt ever bother me08:59
shorneok, Yeah I saw that nop not defined error. We can just fix in the test case itself?08:59
shorneoh, I see, they have a bunch of arch sepecifics there09:00
shorneIll update09:00
olofkYep. I just tried this09:00
shorneok, applied the change and running tests09:03
olofkRebuilding now with your updates09:04
shorneA bit better09:13
shorne# of expected passes            1619809:13
shorne# of unexpected failures        41409:13
olofkWhat?? This is what it looks like for me09:22
olofk# of expected passes1804309:22
olofk# of unexpected failures32809:22
olofkJust finished a regression test too09:22
shorneThats significantly more expected passes09:26
shorneyours is using or1k? not or1ksim?09:27
shorneIf you can somehow get your gdb.sum (file in the testsuite directory) I can do a diff with mine09:31
shorneLooks like you are using gcc 4.9.209:36
shorneI have wallento's latest 5.3.009:37
olofkAh.. true09:37
wallentoI was actually hoping things get better with gcc..09:38
olofkNewer gcc is often more picky09:38
olofkCould be that09:38
wallentoWe also have an eternal bug in C++ virtual tables09:38
wallentoI think philipp sent it to the list a while back09:38
olofkSent the bug, or sent a fix? :)09:38
wallentothe bug09:39
wallentothats way out of my comfort zone09:39
wallentointernal GCC error09:39
wallentoonly in the OpenRISC backend09:39
* olofk looks the other way09:39
shorneProbably not many people going to be doing c++ with openrisc09:40
shorneunless you are building linux desktop for it09:40
shorneI updated the test diff here:
olofkshorne: I always use OpenRISC to run monkey island under scummvm in X windows :)09:41
shorne(renamed your home dir to mine to make the diff more clean)09:41
shorne:) s/updated/uploaded/09:42
olofkSome of the differences are pretty strange09:43
shornehmm, you have a lot of passes for gdb.python09:43
olofkYeah, I saw those. They are unsupported in your case09:44
shornewhere should I enabled that? in gcc?09:44
olofkNo fucking clue09:45
shorne:), ill look past those09:47
shorneother than that its a few things here and there09:47
olofkYeah, and some false positives in the diff as well (like the missing sys/mman.h that is reported differently)09:48
shorneyeah, and environ09:49
shornequite a lot in gdb.cp09:50
shorneI guess thats cpp09:50
shorneMaybe we need to look at cpp stuff, any link to the mail on the bug report?09:53
shorneIll see how complicated it is.09:54
olofkCan't remember seeing that. wallento might have it09:54
wallentoI wiped my university mail and opencores archives are gone..09:54
olofkI should look into newlib and add the missing parts there09:55
olofkwallento: Oh. You think Philipp can help here?09:55
wallentoyes, I triggered him09:55
wallentowow, unlimited private repos with github10:56
wallentobut the pricing model just changed, right?10:56
robtaylorv interesting10:59
wallentoshorne, olofk: "Just for the archive: The problem was with the -freg-struct-return flag, that is not supported with or1k. Bye, Stefan"11:01
wallentothat was one issue we had11:01
wallentophilipp is also searching for the other one. if someone has a local archive of the opencores mailing list it must have been like end of september 201411:03
_franck__wallento: that: ?11:05
wallentothanks, _frank__11:06
wallentothere was a minimal code for reproduction attached I think, like overloaded virtual magic11:06
_franck__I have it, let me upload it11:07
wallentoexcellent, thanks a lot11:07
_franck__stekern replied to this message: "I'll try to figure out what's up, but so far, I tested with earlier versions (4.8.0) of the toolchain, and they fail too. So, it's pretty certain that it's a or1k specific bug."11:07
_franck__there it is:
_franck__shorne: ^11:10
shorne_franck_: thanks, I dont get a failure for this with newlib "or1k-elf-g++ -c -O1"17:09
shorneLet me check what is actually failing in those test cases17:09
shorneyeah the tests cases dont seem to be related to this. They ones with c++ virtual stuff failing are these
shornebut not compiler failures17:13
shornefailures for vtable are intersting, starts here:
shornewith Cannot access memory at address 0xfffffff4, Ill have to jump down to the assembly to see whats going on17:45
shorneIf I do 'p a' I get: p a17:50
shorne$3 = {<V> = <invalid address>, _vptr.A = 0x0, a = 0}17:50
shorne(gdb) p a.fvb()18:40
shorneCannot access memory at address 0xfffffff418:40
shorne(gdb) p a.f()18:40
shorneCannot access memory at address 0xfffffff418:40
shornetest case code is this one:
shorneJust loaded into gdb and running the test commands manually, can reproduce18:41
shornePlayed with the same building for x86, and works fine, at least now I can see what is expected18:45
--- Log closed Thu May 12 00:00:02 2016

Generated by 2.15.2 by Marius Gedminas - find it at!