IRC logs for #openrisc Wednesday, 2012-10-10

stekernat least u-boot is sending something... bogus arp messages00:05
stekerndo we have a value that will alway generate a illegal instruction?06:11
stekern0xbfffffff seems like a candidate06:18
stekernshould this be considered as a bug in gcc?14:45
stekernI can't see any reason to why it would be of any benefit to pad that struct from 14 to 16 bytes, but the question is, is it wrong of gcc to do it?15:00
juliusbmmm because maybe it can use full word copies to relocate it or something?15:39
stekernhmm, what do you mean by "relocate it"?15:46
stekernactually, the ABI in the arch spec has an example of padding like that, but have that been added to comply with what gcc does or the other way around?15:53
juliusbgood question!15:54
juliusbby relocate I meant like copy the struct from one place to another15:54
juliusbcould have been some attempt at optimisation15:54
juliusbbut it doesn't make much sense really, so please ignore it, it was a stab in the dark15:54
juliusbbut that's a good question about whether the spec was updated becuase they couldn't get the compiler doing what they wanted15:55
stekernyeah, I still can't make out what good it would be for15:55
stekern(and I think one of the gcc failures in or1k-linux and or1k-elf is because of this too)15:55
stekernthis is what causing u-boot to send bogus packets15:56
stekernthe ethernet header get padded to 16 bytes15:56
stekernI have "fixed" it by doing: #define ETHER_HDR_SIZE  14//(sizeof(struct ethernet_hdr))15:58
stekernit's beautiful!15:59
stekernthe gcc.dg/builtin-object-size-10.c scan-tree-dump objsz "maximum object size 21"16:01
stekernah, but the example in the arch spec is actually a bit different, it has a double in it, which have an alignment of 4 (according to our abi) 16:17
juliusbah OK16:20
juliusbstekern: what software package was this causing a bug in?16:20
stekernon that clang and gcc agrees16:20
juliusbor the kernel?16:20
stekernI think what they are doing there is wrong, making assumptions like that, but that's besides the current discussion ;)16:21
juliusbstekern: how has your debugging of the mor1kx cappuccino been? have you done much of it?20:13
juliusbmainly, does it work?20:18
olofkI tried to build or1200 against a Virtex-6 today with synplify. Maximum freq I could get was around 70MHz (with a target of 50MHz). Found a worst path with 52 (!) logic levels20:44
olofkIs this a known worst path? Haven't looked much at those things before20:47
juliusbi may have accidentally pressed synthesise on a certain other or1k-compliant core today, using a tool chain which had some libraries from a taiwanese fab.... ahem21:04
juliusbbest case was 250MHz for the prontoespresso core21:04
juliusbworst, a little under 20021:04
juliusbolofk: yeah there's some beasts of paths in the OR1200 :(21:04
juliusblooks like you had MMU enabled too21:05
juliusbwith MMU and cache enabled, it's pretty grim21:05
juliusbbut, with mor1kx on vertex 5, I can hardly crack 10021:05
juliusbit's basically paths which are triggerred on exceptions, but even then I'm not sure if they really are paths21:06
stekernjuliusb: what kind of debugging are you speaking about?21:37
stekernthere are no bugs :)21:43
olofkjuliusb: I'm sorry to hear about the accident21:46
olofkI'm sure you aborted when you realized what a terrible mistake you had done21:48
juliusbstekern: connecting the debugger and gdb, loading an app etc22:00
juliusbolofk: unfortunately it was too late and the results were already infront of me22:01
stekernjuliusb: aah, that works great22:01
juliusbstekern: oh nice one22:01
juliusbhave you tried software breakpoints?22:02
stekernthat I'm not so sure about22:02
juliusbOK, but pausing and resetting it and running it works OK?22:02
juliusbnice one22:02
juliusbstepping shuold work good too actually22:02
juliusbthere's a testbench for that ;)22:02
stekernyes, that works I think22:02
juliusbive made sure stepping code and syscalls and traps and exceptions work22:03
juliusbnothign worse than not being able to step into an exception :(22:03
juliusbhey, are timing estimates out of Xilinx tools the worst case usually?22:19
juliusblike, worst timing corner?22:19
olofkCan't rembemer22:23
juliusbjust curious, not important22:23

Generated by 2.15.2 by Marius Gedminas - find it at!