| --- Log opened Fri Aug 08 00:00:55 2014 | ||
| sb0 | (gplgpu) $12,949/$200,000. must have hurt... | 04:00 |
|---|---|---|
| sb0 | https://twitter.com/EHSMeeting/status/477847276904517632 | 04:01 |
| stekern | poke53282: http://oompa.chokladfabriken.org/openrisc/libstdc++.so | 04:19 |
| stekern | dalias: all valid questions, to which I have no firm answers ;) I'll investigate from where it's coming though | 04:20 |
| dalias | thanks | 04:27 |
| dalias | if there's a good reason i think we need to do something to support it | 04:28 |
| dalias | but if this is just gcc being stupid and generating non-aligned data for no good reason, i think we should fix gcc... | 04:28 |
| dalias | and re-open that bug | 04:28 |
| dalias | the only potential "good reason" i can see is if the reloc actually lies inside .eh_frame and the format of .eh_frame requires it to be misaligned and have a pointer to that function | 04:29 |
| dalias | but i doubt it needs to be misaligned and doubt it has to have a pointer to that function | 04:29 |
| dalias | it doesn't on x86 as far as i can tell | 04:29 |
| dalias | in fact .eh_frame is in the read-only load segment on x86 | 04:29 |
| dalias | and i thought it was always supposed to be read-only | 04:30 |
| stekern | the additional fact that __gxx_personality_v0 isn't a R_ARM_ABS32 relocation in my recent libstdc++ makes me wonder if this is a bug that has been fixed along the way | 04:35 |
| dalias | maybe. which version was making it? | 04:36 |
| dalias | hmm | 04:37 |
| stekern | not sure, I only have the bug reports to rely on that they in fact was present at some point | 04:37 |
| dalias | with 4.7.1 for arm, i have no R_ARM_ABS32 for it in libstdc++.so | 04:37 |
| dalias | just R_ARM_JUMP_SLOT | 04:37 |
| stekern | yeah, same here | 04:38 |
| dalias | i think it's ld making a buggy relocation actually | 04:38 |
| dalias | i have: | 04:39 |
| dalias | https://bugs.gentoo.org/show_bug.cgi?id=394237 | 04:39 |
| dalias | 0x47b5c <__gxx_personality_v0>: @0xa93f4 | 04:39 |
| dalias | Personality routine: 0x43bbc <pthread_detach+0x43bbc> | 04:39 |
| dalias | this is in readelf's dumping of the arm version of unwind info, | 04:39 |
| dalias | Unwind table index '.ARM.exidx' at offset 0xaeb3c contains 1464 entries: | 04:39 |
| dalias | but there's no relocation for this because a reloc isn't needed | 04:39 |
| dalias | it's a reference to the definition in the same .so, not a symbolic reference, and thus doesn't need a reloc | 04:40 |
| dalias | so i think the whole source of this issue was probably broken binutils outputting relocs that shouldn't exist | 04:40 |
| dalias | when the reference was already fully resolved at ld time | 04:40 |
| stekern | mmm | 04:46 |
| dalias | does that sound plausible? | 04:47 |
| stekern | I'll go through the logs for arms elf32-xxx.c and see if I find anything related | 04:47 |
| stekern | I really wish that gcc would adapt meaningful commit messages as a work method... | 06:01 |
| stekern | instead of the completely meaningless 'what I changed' ChangeLogs, I can see from the code what changed | 06:02 |
| stekern | I think our bug is that we don't define ASM_PREFERRED_EH_DATA_FORMAT | 06:18 |
| dalias | uhg | 06:26 |
| dalias | yes these change logs are utterly worthless | 06:26 |
| dalias | it's all written-by-hand duplicates of what git does for you | 06:26 |
| dalias | and absolutely no information on the motivation or effects of the change | 06:26 |
| dalias | i'm not clear on where this idiotic policy came from -- fsf or cygnus/redhat | 06:27 |
| dalias | but it's a huge problem | 06:28 |
| stekern | me neither, at least in binutils it seems to be trending towards the better, where people *first* write some meaningful description and then attach the less useful changelog at the end of the commit message | 06:28 |
| stekern | dalias: defining a proof of concept ASM_PREFERRED_EH_DATA_FORMAT to (flag_pic ? DW_EH_PE_aligned : DW_EH_PE_absptr) removes the first hand problem with the unaligned relocation | 07:17 |
| stekern | now the question is what the non-poc ASM_PREFERRED_EH_DATA_FORMAT should be, since this will still require .eh_frame to be writeable | 07:18 |
| dalias | why does it need to be writable? | 07:19 |
| dalias | non-PIC should only appear in the main program | 07:19 |
| stekern | yeah, I just meant that with the proof-of-concept change I made, a R_OR1K_32 relocation will still be emitted (but aligned this time) | 07:21 |
| dalias | hm | 07:21 |
| dalias | perhaps DW_EH_PE_pcrel ? | 07:24 |
| stekern | yes, it seems other archs use that. | 07:25 |
| stekern | I'll continue experiment more with it, but we can draw the conclusion that this is a bug in our gcc port and musl can continue to assume that relocations should be aligned | 07:26 |
| dalias | aside from the alignment issue, i think it's a bug to have relocs in eh_frame | 07:27 |
| dalias | lots of ppl claim eh_frame/unwinding/exceptions are "free" since the data doesn't have to be loaded from disk if you don't backtrace or throw | 07:28 |
| dalias | but that's obviously not true it it contains relocs | 07:28 |
| dalias | also, making it writable is dangerous | 07:28 |
| dalias | dwarf is a turing-complete language and there are actually attacks involving malicious dwarf code :) | 07:29 |
| dalias | so it should not be writable | 07:29 |
| stekern | makes sense | 07:33 |
| stekern | the larger libc.so was due to -g btw | 07:45 |
| olofk_ | haha. Fun to see Patterson diving into the discussion on the RISC-V on EE Times. He has quite the authority on this subject | 08:16 |
| olofk_ | aha... it's actually Patterson who designed the ISA | 08:17 |
| sb0 | olofk_, and does the ISA work well or is it an academic toy? | 08:18 |
| sb0 | in academia, only one EDA/HDL project out of a million isn't useless crap, so... | 08:19 |
| olofk_ | sb0: Yes, I know. There are plenty of ISA available already that are going nowhere | 08:21 |
| olofk_ | They do seem to have done some things here at least. It apparently runs linux and has been fabbed on 45nm and 28nm if I understand things correctly | 08:22 |
| olofk_ | If you're interested I recommend you read the comments at http://www.eetimes.com/author.asp?section_id=36&doc_id=1323406 | 08:23 |
| olofk_ | No one has brought up lm32 yet, so maybe it's time for that :) | 08:24 |
| sb0 | the proper way to test this thing is to run the HDL source through a synthesizer and benchmark it against lm32 | 08:25 |
| olofk_ | Yeah, about that. It's written in their homemade language "Chisel" | 08:27 |
| sb0 | Patterson's or anyone else's authority is orders of magnitude less important than that test | 08:27 |
| olofk_ | There have been so many cool Open Source Digital design news lately | 08:34 |
| olofk_ | The GPLGPU, Parallax releasing the source of the Propeller CPU, Tachyon releasing their simulator | 08:36 |
| olofk_ | The winds are a-changing in the EDA world | 08:36 |
| olofk_ | dalias: I just read your comment about "malicious dwarf code". I will not be able to sleep tonight | 08:51 |
| ysionneau | wind is changing from the creator point of view | 08:53 |
| ysionneau | from the public ... don't know | 08:53 |
| ysionneau | gplgpu didn't get funded :/ | 08:53 |
| ysionneau | it's a successful project and a marketing failure | 08:53 |
| ysionneau | yet another? | 08:53 |
| olofk_ | ysionneau: No, that's true, but it wasn't a very good kickstarter campaign. | 08:53 |
| ysionneau | I kind of remember they posted very cool video showing their stuff was realling working | 08:54 |
| ysionneau | and this kind of video should have touched even the non-technical public | 08:54 |
| ysionneau | like 3D scenes and things rotating etc that anyone could understand | 08:54 |
| olofk_ | I talked to them and suggested that they should bundle it with some dev board, but it looks like they were basically interested of selling their IP a final time | 08:55 |
| ysionneau | ah ok | 08:55 |
| olofk_ | They didn't really need any kickstarting since all the code was already there | 08:55 |
| ysionneau | for real public interest maybe you're right they should have proposed a real board so that anyone could just buy the board plug it and say "I have an open source graphic card!" | 08:55 |
| olofk_ | Exactly. I think that lost them about 90% of potential customers | 08:56 |
| ysionneau | so you're left with semiconductor profesionnal | 08:56 |
| ysionneau | who have interest in verilog code | 08:56 |
| olofk_ | I suggested adding a wishbone interface as a stretch goal as well, and perhaps hook it up to an OpenRISC | 08:57 |
| olofk_ | Yes, semiconductor professionals, and the weirdos who hang out here :) | 08:57 |
| sb0 | "Love the fact that it runs on Zynq" hahaha | 09:05 |
| olofk_ | Yeah, that was strange | 09:05 |
| olofk_ | Why shouldn't it? | 09:05 |
| sb0 | on an article about a new *CPU CORE* | 09:05 |
| olofk_ | Oh the irony :) | 09:05 |
| ysionneau | love the fact that I can just not use this cool cpu core and use the on-chip arm core! | 09:06 |
| stekern | well, given who wrote that comment, it's not *that* silly | 09:07 |
| stekern | =) | 09:07 |
| sb0 | it's like, installing linux to be cool and then running fdisk /mbr in windows :D http://www.azerty0.ironie.org/hack.html if you speak French | 09:08 |
| ysionneau | ahah | 09:10 |
| stekern | google translator makes it understandable to us non-french speakers too | 09:14 |
| olofk_ | All right! I run the wb_ram testbench with CVC now. Just had to fix one bug in the sim, and do a little workaround | 09:17 |
| sb0 | "We plan to open-source our Rocket core generator written in Chisel in the near future. We are currently in the process of cleaning up the repository." | 09:28 |
| sb0 | reminds me of http://matt.might.net/articles/crapl/ | 09:28 |
| stekern | sb0: that's my main critic to what they are doing wrong, why do they have to do development behind closed doors and *then* release the source? | 09:33 |
| sb0 | likely, because they are ashamed of their code, like most academics | 09:34 |
| sb0 | (and still want research funding) | 09:34 |
| stekern | that's what I think is the openrisc communities strength, that we're completely transparent | 09:35 |
| stekern | and I really like that about the old milkymist development and how m-labs works | 09:35 |
| ysionneau | Yes that's really cool to be able to follow development on mailing list and to just see the github commits poping up on irc | 09:37 |
| ysionneau | + follow irc discussions | 09:37 |
| stekern | I mean, all the discussions about product development you had we're all done on open public forums, there was no unreleased code 'waiting to get cleaned up' etc | 09:37 |
| stekern | s/we're/were | 09:37 |
| stekern | for me, that's what open source / free hardware/software is all about, everybody can come to the table and play | 09:41 |
| stekern | then you also have an open development model, not just open source | 09:43 |
| rah | "128-bit addressing as well as 32-bit and 64-bit" | 11:09 |
| rah | 128-bit!!!1 | 11:09 |
| rah | that's a bit indulgent | 11:09 |
| rah | "OpenRISC may have lost momentum" | 11:11 |
| rah | eh? | 11:11 |
| rah | http://www.eetimes.com/author.asp?section_id=36&doc_id=1323406&page_number=2 | 11:13 |
| ysionneau | that's just shit to say that | 11:45 |
| ysionneau | I see tons of contributions to OpenRISC | 11:45 |
| ysionneau | it seems to be increasing | 11:45 |
| rah | indeed | 11:47 |
| rah | "may have" | 11:48 |
| ysionneau | yes ... | 11:50 |
| rah | read: "I have to put in some reason why openrisc shouldn't be used because I'm arguing for risc-v, so I'll make something up that could be plausible" | 11:50 |
| ysionneau | I see this as a way of advertising their project by shitting on OpenRISC boots | 11:50 |
| rah | right | 11:50 |
| ysionneau | weird to see this strategy knowing that juliusb_ is part of both project | 11:50 |
| rah | let's all glare at juliusb_ | 11:56 |
| * rah glares at juliusb_ | 11:56 | |
| ysionneau | ahah sorry I didn't want to point fingers at him | 11:57 |
| ysionneau | but I just find this strange | 11:57 |
| rah | aye :-) | 11:58 |
| stekern | new mor1kx release in the v2 branch: https://github.com/openrisc/mor1kx/tree/v2.2 | 12:59 |
| ysionneau | \o/ | 13:10 |
| Stman | o/ | 14:19 |
| sb0 | hmm, no answer to my chisel question | 16:02 |
| sb0 | "it's magic!" | 16:03 |
| dalias | olofk_, :) | 16:49 |
| poke53282 | stekern: Indeed, with must-cross it works. At the moment I change my toolchain step by step to do exactly the same as musl-cross. | 17:24 |
| poke53282 | In the end it will be one dumb line which I missed. | 17:25 |
| poke53282 | stekern: I think I found it. I should not compile the musl part of the toolchain with prefix=/usr and install DESTDIR=$SYSROOT. | 18:03 |
| dalias | ? | 18:10 |
| poke53282 | dalias: I use the following buildscript. http://pastie.org/9456397 | 19:14 |
| poke53282 | look at the toolchain_musl. If I use the --prefix=/usr and DESTDIR option, the g++ compiled code doesn't work. Some error in libstdc++. | 19:15 |
| poke53282 | TOOLCHAIN_DIR is /opt/cross/or1k-linux-musl | 19:16 |
| poke53282 | the error happens then somewhere in toolchain_gcc2. Probably some wrong path. | 19:18 |
| poke53282 | If I use the --prefix=/usr I compile musl like to run musl natively and install therefor into $SYSROOT. | 19:20 |
| poke53282 | In the current (working) way, I install musl for the toolchain (especially for gcc) in the folder $(TOOLCHAIN_DIR)/or1k-linux-musl | 19:21 |
| poke53282 | The error encountered is the following. If I compile a basic "hello world" program with g++ and run it does nothing. No output and I have to terminate with CTRL+C. | 19:22 |
| poke53282 | Some error in libstdc++ is responsible for this. | 19:23 |
| dalias | musl doesn't even save the prefix anywhere in the output unless you're using the musl-gcc wrapper script | 19:28 |
| poke53282 | Yes, so I think, that gcc gets confused with the directories. | 19:29 |
| poke53282 | in both cases, musl is installed in different directories. | 19:30 |
| poke53282 | I am not sure, how libgcc and libstdc++ look like if musl cannot be found. And this is I think what happens. But on the other hand, it links in both cases against musl. | 19:30 |
| poke53282 | But one time in $(TOOLCHAIN_DIR)/or1k-linux-musl and one the time in $SYSROOT. | 19:31 |
| poke53282 | dalias: What I can tell you is, that uclibc worked that way. | 19:39 |
| poke53282 | btw: to install native g++ I had to add "typedef struct { char c[16]; } max_align_t;" to stddef.h | 19:55 |
| poke53282 | I am not sure if this solved in one or the other way. But I saw the discussion on the mailing list | 19:56 |
| dalias | that's definitely the wrong definition for max_align_t: it has alignment of 1 :-0 | 19:59 |
| dalias | there's an open question about what the right definition is :/ | 19:59 |
| poke53282 | Ok | 21:11 |
| poke53282 | http://en.cppreference.com/w/cpp/types/max_align_t | 21:12 |
| poke53282 | "std::max_align_t is usually synonymous with the largest scalar type, which is long double on most platforms, and its alignment requirement is either 8 or 16. " | 21:12 |
| poke53282 | Ok, they mean the alignof statement. | 21:13 |
| poke53282 | Then I would put a long double in there. | 21:14 |
| poke53282 | instead of "char c[16]" | 21:14 |
| dalias | the issue is unfortunately complex | 21:15 |
| poke53282 | Yes, I read it. | 21:15 |
| dalias | on the musl list? :) | 21:15 |
| poke53282 | So, make it architecture dependent. | 21:16 |
| poke53282 | Yes, on the musl list. | 21:16 |
| poke53282 | but g++ requires it. | 21:16 |
| poke53282 | in order to compile a native version | 21:16 |
| dalias | i'm not sure if it even needs to be arch-dependent. the biggest problem is that the ABI we want to match has it as 8-byte-aligned on i386 despite there being no portable way to declare an 8-byte-aligned type | 21:17 |
| dalias | *nod* | 21:17 |
| dalias | we will add it | 21:17 |
| dalias | just need to figure out the best solution to this | 21:17 |
| poke53282 | double is always 8 byte? | 21:18 |
| dalias | it always has 8 byte size, but i386 does not have an 8-byte alignment requirement for it | 21:18 |
| poke53282 | ignore all architectures on which this is different :) | 21:18 |
| dalias | the obvious type for max_align_t is something like | 21:19 |
| poke53282 | Ahh, Ok. but the SIMD units like SSE for example need it aligned | 21:19 |
| dalias | union { char __c[16]; long double __ld; double __d; void *__p; long long __ll; }; | 21:19 |
| dalias | but this yields an alignment of 4, not 8, on i386 | 21:19 |
| poke53282 | I understand | 21:19 |
| dalias | despite the ABI we want to match having max_align_t with alignment of 8 | 21:20 |
| dalias | gcc achieves this in their version of stddef.h with __alignas__ or something | 21:20 |
| dalias | but their semantics for __alignas__ are bogus :) | 21:21 |
| dalias | it uses the "preferred alignment for optimization" rather than the "natural alignment of the type" | 21:21 |
| dalias | so | 21:21 |
| dalias | long double __alignas__(long double) __ld; | 21:21 |
| dalias | does not yield the same result as | 21:22 |
| dalias | long double __ld; | 21:22 |
| dalias | which is utterly counter-intuitive and nonsensical :) | 21:22 |
| dalias | anyway what's frustrating is the complete lack of any portable way to represent this alignment requirement (so that stddef.h is not gcc-specific) | 21:22 |
| dalias | i think we can simply expose max_align_t only for C11 or C++11 | 21:23 |
| dalias | and in that cause, use _Alignas(sizeof(long double)) or similar | 21:23 |
| poke53282 | At the moment, it looks like, that it is only used for compiling g++. | 21:24 |
| poke53282 | I understand the problem now, but don't have any solution. Make it always 16. That should be portable for now :) | 21:29 |
| poke53282 | Ok, probably not. | 21:29 |
| poke53282 | Then gcc uses internal another alignment. | 21:30 |
| dalias | we don't have to fix the number as a constant | 21:30 |
| dalias | we just need to do something so that the alignment gets forced up to at least 8 | 21:30 |
| dalias | even on archs where no types have alignment >4 | 21:30 |
| dalias | so maybe | 21:30 |
| dalias | union { char __c[16]; long double __ld; double _Alignas(8) __d; void *__p; long long __ll; }; | 21:31 |
| poke53282 | #define alignof ( <8?8:x ) | 21:31 |
| poke53282 | #define alignof(x) ( alignof_real(x)<8?8:alignof_real(x) ) | 21:32 |
| poke53282 | something like this. | 21:32 |
| poke53282 | Ok, all bad solutions. | 21:33 |
| dalias | ah nasty. the way gcc defined it also makes it hard to duplicate the size of the type in a portable way. because the size of it depends on the alignment of a member | 21:33 |
| poke53282 | but why 8 for architectures? Is there some internal limitation of musl? on openrisc it should be 4 I think. | 21:36 |
| dalias | doesn't or1k abi have aligned long long? | 21:37 |
| poke53282 | Hmm, according to the table which I have in front of me, the highest alignment if 4. Even for double. | 21:41 |
| poke53282 | For the 32 Bit architecture of course | 21:41 |
| poke53282 | Ahh, Ok, but then the vector types. | 21:41 |
| poke53282 | they have an alignment of 8 | 21:41 |
| poke53282 | But as far as I know, they are not used. | 21:42 |
| poke53282 | long long should also give an alignment of 4 according to specification. | 21:42 |
| dalias | oh? that's really unusual, but ok | 21:43 |
| poke53282 | Page 332 in the specification | 21:44 |
| dalias | can you see what you get for _Alignof(max_align_t) and sizeof(max_align_t) with gcc's stddef.h ? | 21:44 |
| dalias | can you give me the link for that? | 21:44 |
| poke53282 | http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fdocs%2Fopenrisc-arch-1.1-rev0.pdf | 21:44 |
| dalias | if so i think it's a rather poor design choice, but probably too late to fix | 21:44 |
| dalias | it makes it impossible to later add 64-bit instructions that actually need 64-bit alignment without changing the abi :( | 21:45 |
| dalias | indeed, alignment is 4 | 21:46 |
| dalias | i suspect max_align_t still has 8-byte alignment tho | 21:46 |
| dalias | btw long double is completely missing from the table | 21:47 |
| poke53282 | Yes, I think that means, that it is just a double. | 21:54 |
| dalias | yeah, i'm sure it's just double, but that should be stated | 21:55 |
| dalias | with an extra line | 21:55 |
| dalias | long double 8 4 Double precision float | 21:55 |
| poke53282 | Yes, should be in there. | 21:55 |
| poke53282 | the alignof function always returns 4 for int, long long, double and long double. | 21:57 |
| dalias | what does it return for max_align_t using the definition from gcc's stddef.h ? | 21:57 |
| poke53282 | Ah, wait. They have there own stddef.h | 21:57 |
| poke53282 | ? | 21:57 |
| dalias | yes gcc provides the headers for a freestanding C implementation | 21:58 |
| dalias | and glibc does not provide these; it relies on gcc's versions | 21:58 |
| dalias | this requires them to be aware of each other's internal macros for controlling what's exposed | 21:58 |
| dalias | and it's really inefficient and ugly when other headers need to get the types from here | 21:58 |
| dalias | (multiple includes of the same header cannot be optimized out by the compiler) | 21:58 |
| dalias | musl does not use gcc's headers at all | 21:58 |
| dalias | it provides a full set of C headers on its own | 21:59 |
| dalias | (this is also needed for supporting some non-gcc compilers like pcc, altho clang mimics gcc here, i think) | 21:59 |
| poke53282 | alignof(max_align_t) => 4 sizeof(max_align_t) => 16 | 22:04 |
| poke53282 | _Alignof is not reckognized | 22:04 |
| poke53282 | complicated stuff. | 22:05 |
| dalias | :) | 22:07 |
| poke53282 | My 64 bit-x86 machine tells me alignof(max_align_t) => 16 sizeof(max_align_t) => 32 | 22:09 |
| dalias | yes | 22:10 |
| dalias | because long double has size/alignment 16 | 22:10 |
| poke53282 | and whats with the AVS unit? The alignment is maybe stricter than 16. | 22:11 |
| poke53282 | AVX unit | 22:11 |
| dalias | max_align_t must have alignment >= the alignment of any fundamental type | 22:12 |
| dalias | and should be considered the highest alignment that's supported "in all contexts" (which is poorly defined :-p) | 22:13 |
| dalias | so for example malloc returns memory with at least the alignment of max_align_t | 22:14 |
| dalias | per the standard, max_align_t is very flexible as long as it's >= any fundamental type's alignment and <= malloc's alignment | 22:16 |
| poke53282 | That's good to know. I always excpected this. | 22:16 |
| dalias | for the purposes of defining an ABI tho, you need to choose a fixed size and alignment for max_align_t for the arch | 22:17 |
| --- Log closed Sat Aug 09 00:00:56 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!