| --- Log opened Wed Jul 30 00:00:42 2014 | ||
| stekern | blueCmd: cool, we should do a port ;) | 02:49 |
|---|---|---|
| stekern | what's another little ball to juggle? | 02:50 |
| stekern | hmm, this is odd... the pointer into the .dynamic section match up when libgcc.so.1 is loaded, but the contents does not | 03:31 |
| stekern | the content matches something in .debug_abbrev | 03:32 |
| dalias | ? | 03:49 |
| stekern | dalias: yes, this is strange... I haven't got to the bottom of it yet | 03:55 |
| dalias | what's the issue? | 03:56 |
| stekern | ld.so segfaults when it tries to work out the deps for libgcc_s.so | 03:58 |
| stekern | and it does so because the content at what should be .dynamic is not what it should, so it treats some 'random' data as DT_NEEDED | 04:01 |
| dalias | is the mmap call being made wrong? | 04:09 |
| dalias | maybe your mmap2 syscall has wacky behavior with respect to the units for the offset | 04:10 |
| dalias | iirc some arch ports were confused about whether it's in units of pages or a fixed 4k unit | 04:10 |
| dalias | imo it should alway | 04:10 |
| dalias | imo it should always be the latter | 04:10 |
| stekern | dalias: hmm, ok... I'll take a look at that, but wouldn't one expect the offsets between the 'random' data (I can find that in the elf) and the actual .dynamic to be something like multiples of 4k then? | 04:31 |
| stekern | here it's 0x13634 | 04:31 |
| dalias | ah probably not that then :) | 04:50 |
| dalias | btw it's best not to have libgcc_s :) | 04:50 |
| stekern | =P | 04:53 |
| Hesham | Which simulator (other than or1ksim) do OpenRISC folks use for debugging the cores? And can I use it to load complex software like RTEMS and debug both HW and SW via it? | 04:56 |
| Hesham | I want to simulate an entire SoC for example and its software, providing all features I can get from HW design that or1ksim does not support. | 04:58 |
| stekern | Hesham: there's qemu too | 05:08 |
| stekern | what peripherals do you miss in or1ksim? | 05:08 |
| Hesham | I noticed that QEMU is kinda newly added, does it support the full features of HW SoC, i.e, orpsoc | 05:09 |
| stekern | then there's of course rtl-simulations | 05:09 |
| Hesham | I miss the memory management architecture, MMU at or1ksim | 05:09 |
| Hesham | it's not fully implemented as of HW, multi-level page tables is an example | 05:10 |
| Hesham | Yes, I am thinking of something like icarus and connect it to GDB, and load RTEMS applications there | 05:10 |
| Hesham | Will this get some attention of the community? | 05:11 |
| stekern | it's possible to do that yes | 05:11 |
| Hesham | I mean, will anyone may want to try to run it? | 05:11 |
| stekern | multi-level page tables, well... I don't know if you should bother with that? it's only mor1kx that support that | 05:13 |
| Hesham | And by using Icarus, I guess I can write software as it run on real HW (mor1k and fuseSoC for example) but it will be slow | 05:13 |
| stekern | yes, you can use verilator for a faster cycle-accurate model | 05:13 |
| Hesham | Well, in RTEMS, being used in embedded systems, we do not need large pages like 16 MB, and 8 KB needs two-levels page tables, right? | 05:14 |
| stekern | but again, what are you missing in or1ksim? | 05:14 |
| stekern | yes, two-level pagetables for 8KB | 05:14 |
| Hesham | Real-time clock, I do not get accurate clock interrupts when configuring the tick timer to tick every 1000ms for example | 05:15 |
| Hesham | We need 8 KB pages, or 1 MB (ARM targets in RTEMS that implement MMU manager used 1 MB pages), so I need two-level page tables which or1ksim does not offer | 05:16 |
| stekern | Hesham: ah, now I understand what you meant. two-level 8KB pagetables are supported by or1ksim, one-level 16MB is not. | 05:17 |
| stekern | I thought when you said 'multi-level' you meant using several different setups (one-level and two-level) at the same time | 05:19 |
| Hesham | We were considering that mixing too, to provide an API for dynamic memory allocation and setting up page attributes dynamically too. | 05:20 |
| stekern | (tick timer) yeah, to get accurate ticks/clock-cycles you'll need a cycle-accurate simulation | 05:21 |
| stekern | I'd use verilator for that | 05:21 |
| Hesham | For the 128 TLB entries, we can get at most 1 MB of memory; TLBs entry would be statically reloaded at startup. But as being RTOS, we want to avoid TLB misses as possible as we can, so 1MB will be small | 05:22 |
| Hesham | Can I use verilator with GDB? | 05:22 |
| stekern | yes | 05:22 |
| stekern | or the verilated model ;) | 05:22 |
| Hesham | This way I can simulate the entire SoC and large software like RTEMS with accurate clocks? | 05:23 |
| stekern | I wouldn't call RTEMS 'large', but yes | 05:23 |
| stekern | you can boot Linux in a verilated model too, so shouldn't be a problem | 05:24 |
| stekern | but what's the 'entire SoC' in your case | 05:25 |
| stekern | ? | 05:25 |
| Hesham | I want to share as much code as possible for RTEMS/or1k with different BSPs. | 05:25 |
| Hesham | For example, mor1k core, UART driver, tick timer, FP unit, and maybe multi-core? | 05:25 |
| stekern | mor1kx doesn't have FPU | 05:26 |
| Hesham | let's make multi-core the least priority, I notices someone has implemented two-core system | 05:26 |
| stekern | otherwise, yes all that is possible in the verilated model | 05:26 |
| Hesham | Is there a tutorial for setting up this verilated model? | 05:27 |
| Hesham | I came across this one which uses Icarus -> http://balau82.wordpress.com/2010/08/07/debugging-openrisc-software-inside-rtl-simulation/ | 05:27 |
| stekern | I don't think there's any step-to-step guides, maybe it's a task for you to do ;) | 05:28 |
| stekern | you'll need this: https://github.com/olofk/fusesoc and this: https://github.com/openrisc/orpsoc-cores | 05:28 |
| Hesham | Sure, I intend to write a blog post when make this works as I did with or1ksim/RTEMS | 05:28 |
| stekern | then you'll need verilator: http://www.veripool.org/ftp/verilator-3.855.tgz | 05:29 |
| Hesham | Yes that's to build the SoC, what about verilated model and GDB parts? | 05:29 |
| Hesham | Great! | 05:29 |
| stekern | then to run a verilated simulation: fusesoc sim --force --sim=verilator mor1kx-generic --elf-load=/path/to/elf | 05:30 |
| Hesham | This way I can simulator a SoC with its software, and (as I have an Atlys board) I can put the design and RTEMS app on this FPGA board with no big effort, right? | 05:31 |
| Hesham | simulate* | 05:31 |
| stekern | to connect gdb you'll need to use this option: '-j, --jtag-server[=PORT] Enable openocd JTAG server, opt. specify PORT' | 05:31 |
| stekern | the mor1kx-generic SoC and the atlys SoC has some differences, but from the peripherals that you listed (uart) they should be identical | 05:33 |
| Hesham | Thanks a lot stekern, I will work on providing a new RTEMS BSP (perhaps called verilator). | 05:33 |
| Hesham | And tick-timer? | 05:34 |
| stekern | or or1k-generic? ;) | 05:34 |
| Hesham | Also, PIC | 05:34 |
| stekern | yes, tick-timer and PIC are embedded in the CPU core | 05:34 |
| stekern | (i.e. mor1kx) | 05:34 |
| Hesham | PIC is not fully implemented in or1ksim | 05:34 |
| stekern | yes it is | 05:35 |
| Hesham | or1k-generic provides more features right? | 05:35 |
| stekern | like what for example? | 05:35 |
| Hesham | I am just inquiring | 05:35 |
| Hesham | I remember I read that mor1k is mini core of or1k | 05:36 |
| Hesham | like FP for example ? | 05:36 |
| stekern | ok, I'm mixing up what you are referring to. | 05:37 |
| Hesham | I thought that or1k-generic embed or1200 core not mor1k | 05:38 |
| stekern | mor1kx doesn't implement all the features of the or1k architecture, no. But there isn't any implementation that does that | 05:38 |
| stekern | or1k-generic was just a suggestion for your BSP | 05:38 |
| Hesham | Ah, I misunderstood that, sorry :) | 05:38 |
| stekern | *a name-suggestion | 05:38 |
| stekern | or1200 have some features that are not implemented in mor1kx (like FPU and MAC) | 05:39 |
| Hesham | And or1200 it can be built using fuseSoC and run on verilator? | 05:39 |
| stekern | mor1kx have some features that are not implemented in or1200 (like hw pagewalk, multi-way caches, support for more tlb entries than 64 etc) | 05:40 |
| stekern | and it's a lot faster | 05:40 |
| stekern | yes, or1200-generic can be used in the same fashion as mor1kx-generic | 05:41 |
| Hesham | I will use mor1k as it seems to be simple and robust, and I think many people use it more than those who use or1200 | 05:42 |
| stekern | I support that decision ;) | 05:42 |
| stekern | I actually got a priv-mail from someone that is planning on porting the or1200 fpu to mor1kx | 05:43 |
| Hesham | Great, we can wait for that while working on providing more drivers and architecture support on RTEMS | 05:45 |
| Hesham | Do you remember about the old RTEMS/or1k port (back to 2005)? | 05:45 |
| stekern | that was before I entered this project, but I know that there was some old rtems port | 05:46 |
| Hesham | It was deleted by 2005, I hope that this new port will be good, so any suggestions for making it successful from you (and OpenRISC community) would be appreciated ;) | 05:48 |
| sb0 | stekern, btw, what exactly are those SPRs that you think are responsible for the large resource usage in mor1kx vs. lm32? | 07:16 |
| stekern | sb0: reviewing that again, I think that statement is not so much true for the setup you are using | 07:19 |
| stekern | i.e. a lot of them are actually already opted out | 07:19 |
| stekern | I still have a couple of local patches where I tried commenting out the remaining ones (that are mandatory by the spec, but could be opted out and still have a functional core) | 07:25 |
| stekern | but it didn't make a huge difference | 07:25 |
| stekern | I don't think there a lot of low hanging fruit left, it's just a matter of combing through everything and do micro-optimizations all over | 07:28 |
| stekern | ...and sometimes unexpected things fall out, like the PIPELINED mul implementation, I don't quite understand why that made such a difference area wise | 07:29 |
| sb0 | mhh | 07:37 |
| sb0 | how did lm32 (and microblaze and nios) do it? | 07:37 |
| stekern | 'do it' == become small? | 07:40 |
| sb0 | yes | 07:41 |
| stekern | how should I know? I didn't sit with the design teams ;) but I bet that they did some optimization iterations on those too | 07:42 |
| Hesham | stekern: I have installed fusesoc, verilator, compiled simple hello.elf with bare-metal or1k-elf-gcc, and when typing the command you provided "fusesoc sim --force --sim=verilator mor1kx-generic --elf-load hello.elf" the simulator starts and go to the part of loading the hello.elf and produce an error of unable to load the elf file | 07:43 |
| Hesham | Loading hello.elf | 07:44 |
| Hesham | Can't open hello.elf | 07:44 |
| Hesham | Error loading elf file | 07:44 |
| Hesham | TOP.v.mor1kx0.bus_gen.ibus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK | 07:44 |
| Hesham | TOP.v.mor1kx0.bus_gen.dbus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK | 07:44 |
| stekern | sb0: how large was lm32 now again (in the videomixer soc)? | 07:44 |
| sb0 | 2400 LUTs | 07:44 |
| sb0 | mor1kx is, like, 5k | 07:45 |
| stekern | ? | 07:46 |
| stekern | http://pastie.org/pastes/9431038/text | 07:46 |
| stekern | 2419 | 07:46 |
| stekern | but that's with the PIPELINED mul iirc | 07:47 |
| sb0 | which doesn't meet timing... | 07:48 |
| stekern | yes.. but the difference between the PIPELINED and THREESTAGE isn't 2.5k LUTs | 07:48 |
| stekern | http://pastie.org/pastes/9431043/text | 07:50 |
| stekern | that's with THREESTAGE | 07:50 |
| stekern | 2757 | 07:51 |
| sb0 | well, using lm32 does remove 1600 LUTs from the soc | 07:53 |
| sb0 | and I'm sure of this number | 07:53 |
| stekern | interesting. so some logic increase somewhere else then | 07:54 |
| stekern | do you have an mrp around? | 07:54 |
| stekern | I can do a build myself if not though | 07:55 |
| sb0 | not on this laptop... you can test on misoc with: ./make.py -t simple -Ot cpu lm32/or1k build-bitstream | 07:56 |
| sb0 | sorry, -Ot cpu_type | 07:57 |
| sb0 | that 1600 figure is from last month, it should be a bit smaller with the couple new optimizations you made since then | 07:58 |
| stekern | ok, no problem, I'll take a look | 07:59 |
| sb0 | thx :) | 08:00 |
| Hesham | I am able to run mor1kx and hello.elf using fusesoc now and I got exit message successfully. However the printf("hello"); does not emit anything to the console, do I miss something? | 08:12 |
| stekern | sb0: there was a simpler explanation, you remembered the lut count for lm32 wrong. it's 1484 | 08:14 |
| stekern | so, a lot of micro-optimizations left to do ;) | 08:17 |
| stekern | there's of course subtle differences between the archs all over the place, like that you can't turn off caches at runtime in lm32. That will save you a big mux in the fetch unit | 08:18 |
| stekern | Hesham: no, that should work | 08:20 |
| stekern | (fetch and lsu unit) | 08:21 |
| Hesham | fusesoc sim --force --sim=verilator mor1kx-generic does this command fetch the UART core? | 08:24 |
| stekern | yes | 08:25 |
| Hesham | Not sure what's the problem, this is the message I got from the previous command | 08:25 |
| Hesham | Program header 0: addr 0x00000000, size 0x00011174 | 08:25 |
| Hesham | Program header 1: addr 0x00013174, size 0x00000A80 | 08:25 |
| Hesham | TOP.v.mor1kx0.bus_gen.ibus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK | 08:25 |
| Hesham | TOP.v.mor1kx0.bus_gen.dbus_bridge: Wishbone bus IF is B3_REGISTERED_FEEDBACK | 08:25 |
| Hesham | Success! Got NOP_EXIT. Exiting (27316) | 08:25 |
| Hesham | Simulation ended at PC = 0000d760 (27317) | 08:25 |
| Hesham | hello.elf simple printf("Hello"); from the main | 08:26 |
| Hesham | Does the UART address is 0x9000000 as usual? | 08:28 |
| Hesham | Thanks stekern for all your help. Everything is working fine now, the problem with some conflicts with my toolchain. | 09:01 |
| blueCmd | stekern: *TODO list explores* | 09:10 |
| -!- simoncoo1 is now known as simoncook | 09:11 | |
| maxpaln | stekern: FYI - the test is now passing :-) | 09:14 |
| maxpaln | A fresh pair of eyes did indeed solve the problem. Although I can't be sure exactly what caused the issue - I cleaned up several things that were wrong. The result is a passing simulation :-) | 09:15 |
| maxpaln | starting a broader regression now | 09:20 |
| stekern | blueCmd: d? | 09:22 |
| stekern | Hesham and maxpaln: great! =P | 09:22 |
| blueCmd | stekern: yes, explodes | 09:36 |
| blueCmd | explores would be something though | 09:37 |
| -!- Netsplit *.net <-> *.split quits: aburgess, jonmasters, olofk | 09:44 | |
| -!- Netsplit over, joins: aburgess | 09:45 | |
| stekern | hmm... I get fun results with mmap.. | 10:43 |
| stekern | nm... I'm holding it wrong | 11:01 |
| -!- clopez_ is now known as clopez | 11:05 | |
| stekern | ok, holding it right yields fun result too... and consistent with what happens in musl | 11:07 |
| stekern | ok... so this whole thing is most likely related to page size and mmap2 | 11:10 |
| stekern | -'most likely' | 11:14 |
| stekern | what a mess... | 11:20 |
| stekern | I'd consider that a kernel bug | 11:20 |
| stekern | blueCmd: back to the original problem with R_OR1K_INSN_REL_26 in libgcc_s.so, does the glibc dynlinker resolve those? | 11:24 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/or1k/dl-machine.h#L246 | 12:05 |
| blueCmd | yep | 12:05 |
| stekern | blueCmd: follow-up question - is the result of that correct? | 12:09 |
| blueCmd | stekern: for this case or in general? | 12:18 |
| blueCmd | either way I don't know, but if it isn't correct in general I would think I would see more crashes | 12:19 |
| stekern | both, but for this case is of course more interesting | 12:19 |
| stekern | well, from what I understand, R_OR1K_INSN_REL_26 shouldn't be present in dynlibs. and the compiler will not produce code that will result in such relocations, so I don't think it is that common | 12:20 |
| stekern | ok, probably something else, hacking around those relocations I get a bus error | 12:41 |
| stekern | so, maybe I'm now at the same point as you ;) | 12:42 |
| blueCmd | stekern: :D | 13:21 |
| blueCmd | nice, Matjaz responded to my GCC email. I think we're only missing Jungsook now | 14:03 |
| stekern | \o/ | 14:18 |
| stekern | this bus error seems to come from a failure in my test program... | 14:18 |
| stekern | blueCmd: can you give me the program that fails to call __umodsi3? | 14:26 |
| blueCmd | stekern: a binary? | 14:46 |
| stekern | yes | 14:49 |
| blueCmd | stekern: I'm afraid that will cost you license fees | 14:50 |
| blueCmd | stekern: http://openrisc.debian.net/tmp/rdfind should use modsi at least | 14:52 |
| blueCmd | I don't have any broken chroots open atm so I couldn't test | 14:53 |
| blueCmd | let me know if you want something more exact | 14:53 |
| stekern | that's fine, I might not need it | 14:53 |
| stekern | ok, my rudimentary __umodsi3 test works now | 14:57 |
| stekern | blueCmd: did you recompile rdfind after you added the .size statement? | 14:58 |
| stekern | probably, since you got the __modsi in the got | 14:59 |
| stekern | so, then I don't know why it doesn't work for you | 15:03 |
| stekern | blueCmd: can you test running this: http://pastie.org/9429200 | 15:11 |
| stekern | compiled with: or1k-linux-gcc -O2 umodsi.c -shared-libgcc -o umodsi | 15:11 |
| stekern | and if that fails, test applying this hack to or1k.S: http://pastie.org/9431862 | 15:12 |
| stekern | it's against openrisc/or1k-gcc, so your changes are there too | 15:12 |
| blueCmd | stekern: no, I didn't recompile | 15:28 |
| blueCmd | I don't want to recompile all packages that linked to libgcc | 15:28 |
| stekern | you only need to recompile the once that link to it dynamically | 15:32 |
| stekern | but the file you gave me didn't look broken like mine before I added the .size info | 15:33 |
| stekern | and it complained about missing that info when compiling | 15:34 |
| blueCmd | stekern: apt-cache rdepends libgcc1 | wc -l | 15:35 |
| blueCmd | 4466 | 15:35 |
| blueCmd | so forgive me for not wanting to recompile "only" the packages affected :) | 15:35 |
| stekern | you didn't read what i said | 15:36 |
| blueCmd | stekern: well, I answered the 1st thing. I didn't quite understand the two follow-up sentences | 15:37 |
| blueCmd | and I assumed 's/once/ones' | 15:37 |
| stekern | yes | 15:37 |
| stekern | but from that I assume that when you say that you haven't recompiled, you mean that you rdfind is compiled with 4.8.x? | 15:39 |
| blueCmd | yep | 15:40 |
| stekern | moving back, are you saying that none of those 4466 link againts libgcc statically? | 15:41 |
| blueCmd | stekern: yes | 15:41 |
| blueCmd | stekern: statically would infer a build-dependency, not a binary dependency | 15:42 |
| blueCmd | I'm not sure if this is the whole tree or just the first level dependencies though, let me check that | 15:42 |
| blueCmd | but I don't know why we are discussing this, surely maintaining the same structure of exported function is trivial? | 15:43 |
| stekern | but either way, you'd only have to recompile the ones that were built against the libgcc that were missing @function and .size | 15:44 |
| blueCmd | (apparently not, but what I'm saying is that this has to be something small) | 15:44 |
| blueCmd | stekern: I have no such binaries | 15:44 |
| stekern | exactly, so no issue | 15:44 |
| blueCmd | but things still crash with @function and .size | 15:44 |
| stekern | but I thought you had rebuilt the apps you noticed failing | 15:44 |
| stekern | yes, I got that... So something is up with that | 15:45 |
| blueCmd | right. no, I'm waay to lazy for that | 15:45 |
| blueCmd | you should know that | 15:45 |
| blueCmd | :) | 15:45 |
| stekern | so... I need to build a libgcc with the old C versions, compile my test-prog against that and then try to run that against the asm libgcc | 15:46 |
| blueCmd | yes, that is what I would do as the next step | 15:46 |
| blueCmd | but going back to my lazyness, that is why I involved you | 15:47 |
| blueCmd | but it's nice to know that you have the same issue now atleast (or something that looks related) | 15:47 |
| stekern | right now, I have no issues | 15:50 |
| stekern | ...well not related to this at least.. | 15:51 |
| blueCmd | hm | 15:53 |
| blueCmd | what was that crash you were talking about earlier? | 15:54 |
| stekern | I have 'resolved' all crashes | 15:59 |
| stekern | 1) was due to that our sys_mmap2 in Linux is buggy | 16:00 |
| stekern | 2) was due to the R_OR1K_INSN_REL_26, musl doesn't resolve them | 16:02 |
| stekern | 3) was due to the missing @function and .size | 16:03 |
| blueCmd | hm | 16:08 |
| blueCmd | I might have been sloppy looking at the final crash. it seems to go past umodsi3 now and go to strcasecmp | 16:09 |
| blueCmd | I'm going to rebuild gcc and glibc and see what happens | 16:09 |
| stekern | ;) | 16:10 |
| blueCmd | takes about a day to build gcc and about 6 hours to build glibc | 16:10 |
| blueCmd | so, I'll be right back! | 16:10 |
| stekern | good, because you'd anyway be on your own, the test app built against C libgcc worked when dynlinking against asm libgcc | 16:11 |
| stekern | blueCmd: musl takes about 1.5 minute to build, without -j | 16:14 |
| blueCmd | stekern: natively? ;) | 16:15 |
| stekern | sure, on a really fast or1k machine ;) | 16:15 |
| stekern | but, no, cross-build | 16:15 |
| blueCmd | stekern: yeah, I cannot run with -j and I need to compile it natively for debian | 16:18 |
| blueCmd | rebuilding my whole development setup takes ~10 min from zero to working rootfs otherwise, so that's fine | 16:18 |
| blueCmd | stekern: why would you link to libgcc staticly btw? | 16:24 |
| poke53281 | blueCmd: Try to start qemu with the no flags option. I am pretty sure your compile time will be significantly reduced.. | 16:28 |
| blueCmd | poke53281: oh, what flag is that? | 16:32 |
| stekern | blueCmd: because otherwise stekern might break the dynamic one | 16:34 |
| stekern | joking aside, try compiling my test without the -shared-libgcc flag, and it will statically link libgcc | 16:35 |
| blueCmd | hm | 16:35 |
| blueCmd | maybe it is standard to statically link it and that's why the whole system isn't broken and only a handful | 16:36 |
| blueCmd | and libgcc contains some other thing that the libraries need | 16:36 |
| stekern | dalias: any suggestions what to do with a broken sys_mmap2...? | 17:02 |
| blueCmd | stekern: you're not speaking of the PAGE_SIZE = 14 and not = 13 thing are you? | 17:03 |
| blueCmd | or whatever that constant is called | 17:04 |
| stekern | 14? | 17:04 |
| stekern | but no | 17:04 |
| blueCmd | or 13 / 12 | 17:04 |
| stekern | our page size is 8KB | 17:05 |
| * blueCmd 's greatest strength is his attention to details | 17:05 | |
| stekern | not 14 bytes ;) | 17:05 |
| blueCmd | PAGE_SHIFT | 17:05 |
| blueCmd | something like that | 17:05 |
| blueCmd | it's 2<<14 | 17:05 |
| stekern | no, it's 2<<13 == 8192 | 17:05 |
| stekern | err | 17:06 |
| stekern | you tricked me | 17:06 |
| stekern | 1<<13 | 17:06 |
| blueCmd | yeah, don't look at the numbers - i'm buzzing around about the fact that IIRC we're not using the same as 'all the other' arches | 17:07 |
| stekern | yeah, but that's not an issue per se | 17:07 |
| stekern | the issue is that mmap2 should take the offset argument in multiples of 4kb, but our kernel implementation interprets the offset argument as 8kb | 17:08 |
| stekern | *as multiples of 8kb | 17:09 |
| stekern | at least if we're going to follow this: http://man7.org/linux/man-pages/man2/mmap2.2.html | 17:09 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/unix/sysv/linux/or1k/sysdep.h#L27 | 17:10 |
| blueCmd | THERE! that was annoyingly hard to find | 17:10 |
| stekern | yes, I know, both our glibc and uclibc are correcting for the kernel bug | 17:11 |
| blueCmd | right. I always thought there was a grander idea behind that | 17:11 |
| blueCmd | more than a bug | 17:11 |
| stekern | to comfort ourselfs, arc seems to be even more broken... | 17:12 |
| stekern | arc can be configured to have 4/8/16KB page tables, and mmap2 follows that configure... | 17:13 |
| blueCmd | hahaha | 17:13 |
| blueCmd | let's not do that | 17:13 |
| blueCmd | stekern: do you know how syscalls are compiled for glibc? I find the way they do it kind of hillarious | 17:36 |
| blueCmd | a pain to debug if you don't know how it's done, but yeah | 17:36 |
| blueCmd | spoiler: http://aa679be053b19916.paste.se/ | 17:37 |
| stekern | heh | 17:59 |
| dalias | stekern, is sys_mmap2 broken? | 18:15 |
| dalias | ah i see... | 18:16 |
| dalias | the kernel _REALLY_ needs comments in the source to warn porters about this issue | 18:16 |
| dalias | sys_mmap2 should always be using 4k units | 18:16 |
| dalias | it especially should not use a runtime-variable pagesize | 18:16 |
| dalias | if you want to keep the constant 8k size then we need to make musl aware of it | 18:17 |
| dalias | so far musl does not support any of the wacky archs where mmap2 behaves badly | 18:17 |
| dalias | FYI, microblaze _ALMOST_ had a horrible regression in this area a few months back | 18:18 |
| stekern | yeah, I don't think we'll get much forward trying to force a change in the kernel | 18:18 |
| dalias | but i caught the message on the glibc list that was about to break it and make an ABI-compat nightmare | 18:18 |
| dalias | and we got it reverted before it got out into the wild :) | 18:18 |
| stekern | dalias: well, welcome to wacky or1k land ;) | 18:19 |
| stekern | or perhaps :/ | 18:19 |
| dalias | stekern, so for or1k, mmap2 shift matches pagesize? | 18:20 |
| dalias | and pagesize is runtime-variable (obtained from auxv) right? | 18:20 |
| dalias | note that PAGE_SIZE, not PAGE_SHIFT, is what we get... | 18:21 |
| dalias | so now we need division in mmap() :-p | 18:21 |
| stekern | yes ;) | 18:24 |
| stekern | but on a practical level, our pagesize isn't really variable, it's always 8KB | 18:24 |
| blueCmd | yes | 18:25 |
| dalias | but from an abi standpoint we need to treat it as such | 18:26 |
| dalias | right? | 18:26 |
| blueCmd | no | 18:26 |
| stekern | not really, it's defined to be 8KB in the ABI | 18:26 |
| blueCmd | it has "always" been 8K | 18:26 |
| dalias | well why doesn't limits.h define PAGE_SIZE then? :) | 18:44 |
| dalias | right now musl treats it as an arch where the page size is runtime variable | 18:44 |
| dalias | i would be very happy to define it to 8k and treat that as a permanent part of the abi tho, if you are | 18:44 |
| dalias | variable pagesize is stupid | 18:44 |
| blueCmd | what is the constant supposed to be called? PAGE_SIZE? | 18:45 |
| blueCmd | my x86_64 doesn't have a constant for that | 18:46 |
| blueCmd | it has one in sys/user.h though | 18:46 |
| dalias | bluecmd, that's glibc. they removed PAGE_SIZE on all archs because of their HURD mentality that everything is variable/unlimited-limit | 18:47 |
| dalias | they also removed PATH_MAX for the same reason | 18:48 |
| dalias | on musl, PAGE_SIZE exists for most archs in bits/limits.h | 18:48 |
| ysionneau | well isn't the page size variable on most modern MMU ? | 18:50 |
| ysionneau | or maybe this feature isn't used on any OS? | 18:51 |
| dalias | i dunno, probably not | 18:51 |
| dalias | if it's variable at runtime on a given piece of hardware, then it doesn't have to be variable in the ABI | 18:52 |
| dalias | you just pick the best (smallest) available option | 18:52 |
| dalias | on the other hand, if the choice of page size is limited by the hardware, and the same ISA has different page sizes on different hardware | 18:52 |
| dalias | then the ABI for this ISA has to support variable pagesize | 18:52 |
| dalias | this is the case with mips | 18:53 |
| stekern | dalias: (PAGE_SIZE in limits.h) it very well can be, I just noticed today that we're using the runtime variable | 18:57 |
| dalias | stekern, making it constant generates mildly better code in a few places | 18:59 |
| stekern | yeah, I'm happy to make it constant. the only reason it isn't alreadyt was just an oversight from my side. | 19:02 |
| dalias | stekern, ok. so there are two issues. 1. add SYSCALL_MMAP2_UNIT macro with value 8k for or1k | 19:24 |
| dalias | 2. define PAGE_SIZE to 8k | 19:24 |
| stekern | dalias: right | 19:35 |
| dalias | btw some interesting history, at least as i understand it | 19:48 |
| dalias | i think the push to #undef PAGE_SIZE came around the time people started getting interested in huge pages on x86[_64] | 19:48 |
| dalias | because there was a serious misunderstanding of how to use them right at first, and of what PAGE_SIZE means | 19:49 |
| dalias | and some people assumed you would run processes with a page_size of 2MB or 2GB for using huge pages... | 19:49 |
| dalias | (which would of course be idiotic; you'd use all your ram in no time, and swapping becomes totally impractical) | 19:50 |
| dalias | PAGE_SIZE is simply the mmap granularity | 19:53 |
| poke53281 | blueCmd: https://github.com/s-macke/qemu/commit/8915c50fa9f64938d54a61437006c2789bdf9dae | 23:11 |
| poke53281 | and I wrote a manual a few months ago in the chat. | 23:12 |
| blueCmd | poke53281: ooh, nice - yes I remember this now when reading the message | 23:35 |
| --- Log closed Thu Jul 31 00:00:43 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!