| stekern | at least u-boot is sending something... bogus arp messages | 00:05 |
|---|---|---|
| stekern | do we have a value that will alway generate a illegal instruction? | 06:11 |
| stekern | 0xbfffffff seems like a candidate | 06:18 |
| stekern | should this be considered as a bug in gcc? | 14:45 |
| stekern | http://pastie.org/5029197 | 14:45 |
| stekern | I 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 |
| juliusb | mmm because maybe it can use full word copies to relocate it or something? | 15:39 |
| stekern | hmm, what do you mean by "relocate it"? | 15:46 |
| stekern | actually, 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 |
| juliusb | good question! | 15:54 |
| juliusb | by relocate I meant like copy the struct from one place to another | 15:54 |
| juliusb | could have been some attempt at optimisation | 15:54 |
| juliusb | but it doesn't make much sense really, so please ignore it, it was a stab in the dark | 15:54 |
| juliusb | but that's a good question about whether the spec was updated becuase they couldn't get the compiler doing what they wanted | 15:55 |
| stekern | yeah, I still can't make out what good it would be for | 15:55 |
| stekern | (and I think one of the gcc failures in or1k-linux and or1k-elf is because of this too) | 15:55 |
| stekern | this is what causing u-boot to send bogus packets | 15:56 |
| stekern | the ethernet header get padded to 16 bytes | 15:56 |
| stekern | I have "fixed" it by doing: #define ETHER_HDR_SIZE 14//(sizeof(struct ethernet_hdr)) | 15:58 |
| stekern | it's beautiful! | 15:59 |
| stekern | http://opencores.org/or1k/Newlib_tool_chain_test_results#FAIL_tests_2 | 16:00 |
| stekern | the gcc.dg/builtin-object-size-10.c scan-tree-dump objsz "maximum object size 21" | 16:01 |
| stekern | ah, 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 |
| juliusb | ah OK | 16:20 |
| juliusb | stekern: what software package was this causing a bug in? | 16:20 |
| juliusb | u-boot? | 16:20 |
| stekern | on that clang and gcc agrees | 16:20 |
| juliusb | or the kernel? | 16:20 |
| stekern | u-boot | 16:20 |
| juliusb | rightio | 16:20 |
| stekern | I think what they are doing there is wrong, making assumptions like that, but that's besides the current discussion ;) | 16:21 |
| juliusb | stekern: how has your debugging of the mor1kx cappuccino been? have you done much of it? | 20:13 |
| juliusb | mainly, does it work? | 20:18 |
| juliusb | hehe | 20:18 |
| olofk | I 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 levels | 20:44 |
| olofk | http://pastebin.com/5LGsuj5y | 20:46 |
| olofk | Is this a known worst path? Haven't looked much at those things before | 20:47 |
| juliusb | i 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.... ahem | 21:04 |
| juliusb | best case was 250MHz for the prontoespresso core | 21:04 |
| juliusb | worst, a little under 200 | 21:04 |
| juliusb | olofk: yeah there's some beasts of paths in the OR1200 :( | 21:04 |
| juliusb | looks like you had MMU enabled too | 21:05 |
| juliusb | with MMU and cache enabled, it's pretty grim | 21:05 |
| juliusb | but, with mor1kx on vertex 5, I can hardly crack 100 | 21:05 |
| juliusb | virtex5 | 21:05 |
| juliusb | it's basically paths which are triggerred on exceptions, but even then I'm not sure if they really are paths | 21:06 |
| juliusb | bbl | 21:07 |
| stekern | juliusb: what kind of debugging are you speaking about? | 21:37 |
| stekern | there are no bugs :) | 21:43 |
| olofk | juliusb: I'm sorry to hear about the accident | 21:46 |
| olofk | I'm sure you aborted when you realized what a terrible mistake you had done | 21:48 |
| juliusb | stekern: connecting the debugger and gdb, loading an app etc | 22:00 |
| juliusb | olofk: unfortunately it was too late and the results were already infront of me | 22:01 |
| stekern | juliusb: aah, that works great | 22:01 |
| juliusb | stekern: oh nice one | 22:01 |
| juliusb | have you tried software breakpoints? | 22:02 |
| stekern | that I'm not so sure about | 22:02 |
| juliusb | OK, but pausing and resetting it and running it works OK? | 22:02 |
| stekern | yup | 22:02 |
| juliusb | nice one | 22:02 |
| juliusb | stepping shuold work good too actually | 22:02 |
| juliusb | there's a testbench for that ;) | 22:02 |
| stekern | yes, that works I think | 22:02 |
| juliusb | ive made sure stepping code and syscalls and traps and exceptions work | 22:03 |
| juliusb | nothign worse than not being able to step into an exception :( | 22:03 |
| juliusb | hey, are timing estimates out of Xilinx tools the worst case usually? | 22:19 |
| juliusb | like, worst timing corner? | 22:19 |
| olofk | Can't rembemer | 22:23 |
| juliusb | just curious, not important | 22:23 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!