IRC logs for #openrisc Friday, 2014-08-08

--- Log opened Fri Aug 08 00:00:55 2014
sb0(gplgpu) $12,949/$200,000. must have hurt...04:00
stekerndalias: all valid questions, to which I have no firm answers ;) I'll investigate from where it's coming though04:20
daliasif there's a good reason i think we need to do something to support it04:28
daliasbut if this is just gcc being stupid and generating non-aligned data for no good reason, i think we should fix gcc...04:28
daliasand re-open that bug04:28
daliasthe 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 function04:29
daliasbut i doubt it needs to be misaligned and doubt it has to have a pointer to that function04:29
daliasit doesn't on x86 as far as i can tell04:29
daliasin fact .eh_frame is in the read-only load segment on x8604:29
daliasand i thought it was always supposed to be read-only04:30
stekernthe 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 way04:35
daliasmaybe. which version was making it?04:36
stekernnot sure, I only have the bug reports to rely on that they in fact was present at some point04:37
daliaswith 4.7.1 for arm, i have no R_ARM_ABS32 for it in libstdc++.so04:37
daliasjust R_ARM_JUMP_SLOT04:37
stekernyeah, same here04:38
daliasi think it's ld making a buggy relocation actually04:38
daliasi have:04:39
dalias0x47b5c <__gxx_personality_v0>: @0xa93f404:39
dalias  Personality routine: 0x43bbc <pthread_detach+0x43bbc>04:39
daliasthis is in readelf's dumping of the arm version of unwind info,04:39
daliasUnwind table index '.ARM.exidx' at offset 0xaeb3c contains 1464 entries:04:39
daliasbut there's no relocation for this because a reloc isn't needed04:39
daliasit's a reference to the definition in the same .so, not a symbolic reference, and thus doesn't need a reloc04:40
daliasso i think the whole source of this issue was probably broken binutils outputting relocs that shouldn't exist04:40
daliaswhen the reference was already fully resolved at ld time04:40
daliasdoes that sound plausible?04:47
stekernI'll go through the logs for arms elf32-xxx.c and see if I find anything related04:47
stekernI really wish that gcc would adapt meaningful commit messages as a work method...06:01
stekerninstead of the completely meaningless 'what I changed' ChangeLogs, I can see from the code what changed06:02
stekernI think our bug is that we don't define ASM_PREFERRED_EH_DATA_FORMAT06:18
daliasyes these change logs are utterly worthless06:26
daliasit's all written-by-hand duplicates of what git does for you06:26
daliasand absolutely no information on the motivation or effects of the change06:26
daliasi'm not clear on where this idiotic policy came from -- fsf or cygnus/redhat06:27
daliasbut it's a huge problem06:28
stekernme 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 message06:28
stekerndalias: 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 relocation07:17
stekernnow the question is what the non-poc ASM_PREFERRED_EH_DATA_FORMAT should be, since this will still require .eh_frame to be writeable07:18
daliaswhy does it need to be writable?07:19
daliasnon-PIC should only appear in the main program07:19
stekernyeah, 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
daliasperhaps DW_EH_PE_pcrel ?07:24
stekernyes, it seems other archs use that.07:25
stekernI'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 aligned07:26
daliasaside from the alignment issue, i think it's a bug to have relocs in eh_frame07:27
daliaslots 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 throw07:28
daliasbut that's obviously not true it it contains relocs07:28
daliasalso, making it writable is dangerous07:28
daliasdwarf is a turing-complete language and there are actually attacks involving malicious dwarf code :)07:29
daliasso it should not be writable07:29
stekernmakes sense07:33
stekernthe larger was due to -g btw07: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 subject08:16
olofk_aha... it's actually Patterson who designed the ISA08:17
sb0olofk_, and does the ISA work well or is it an academic toy?08:18
sb0in 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 nowhere08: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 correctly08:22
olofk_If you're interested I recommend you read the comments at
olofk_No one has brought up lm32 yet, so maybe it's time for that :)08:24
sb0the proper way to test this thing is to run the HDL source through a synthesizer and benchmark it against lm3208:25
olofk_Yeah, about that. It's written in their homemade language "Chisel"08:27
sb0Patterson's or anyone else's authority is orders of magnitude less important than that test08:27
olofk_There have been so many cool Open Source Digital design news lately08:34
olofk_The GPLGPU, Parallax releasing the source of the Propeller CPU, Tachyon releasing their simulator08:36
olofk_The winds are a-changing in the EDA world08:36
olofk_dalias: I just read your comment about "malicious dwarf code". I will not be able to sleep tonight08:51
ysionneauwind is changing from the creator point of view08:53
ysionneaufrom the public ... don't know08:53
ysionneaugplgpu didn't get funded :/08:53
ysionneauit's a successful project and a marketing failure08:53
ysionneauyet another?08:53
olofk_ysionneau: No, that's true, but it wasn't a very good kickstarter campaign.08:53
ysionneauI kind of remember they posted very cool video showing their stuff was realling working08:54
ysionneauand this kind of video should have touched even the non-technical public08:54
ysionneaulike 3D scenes and things rotating etc that anyone could understand08: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 time08:55
ysionneauah ok08:55
olofk_They didn't really need any kickstarting since all the code was already there08:55
ysionneaufor 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 customers08:56
ysionneauso you're left with semiconductor profesionnal08:56
ysionneauwho have interest in verilog code08:56
olofk_I suggested adding a wishbone interface as a stretch goal as well, and perhaps hook it up to an OpenRISC08:57
olofk_Yes, semiconductor professionals, and the weirdos who hang out here :)08:57
sb0"Love the fact that it runs on Zynq" hahaha09:05
olofk_Yeah, that was strange09:05
olofk_Why shouldn't it?09:05
sb0on an article about a new *CPU CORE*09:05
olofk_Oh the irony :)09:05
ysionneaulove the fact that I can just not use this cool cpu core and use the on-chip arm core!09:06
stekernwell, given who wrote that comment, it's not *that* silly09:07
sb0it's like, installing linux to be cool and then running fdisk /mbr in windows :D if you speak French09:08
stekerngoogle translator makes it understandable to us non-french speakers too09: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 workaround09: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
sb0reminds me of
stekernsb0: 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
sb0likely, because they are ashamed of their code, like most academics09:34
sb0(and still want research funding)09:34
stekernthat's what I think is the openrisc communities strength, that we're completely transparent09:35
stekernand I really like that about the old milkymist development and how m-labs works09:35
ysionneauYes that's really cool to be able to follow development on mailing list and to just see the github commits poping up on irc09:37
ysionneau+ follow irc discussions09:37
stekernI 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' etc09:37
stekernfor me, that's what open source / free hardware/software is all about, everybody can come to the table and play09:41
stekernthen you also have an open development model, not just open source09:43
rah"128-bit addressing as well as 32-bit and 64-bit"11:09
rahthat's a bit indulgent11:09
rah"OpenRISC may have lost momentum"11:11
ysionneauthat's just shit to say that11:45
ysionneauI see tons of contributions to OpenRISC11:45
ysionneauit seems to be increasing11:45
rah"may have"11:48
ysionneauyes ...11:50
rahread: "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
ysionneauI see this as a way of advertising their project by shitting on OpenRISC boots11:50
ysionneauweird to see this strategy knowing that juliusb_ is part of both project11:50
rahlet's all glare at juliusb_11:56
* rah glares at juliusb_ 11:56
ysionneauahah sorry I didn't want to point fingers at him11:57
ysionneaubut I just find this strange11:57
rahaye :-)11:58
stekernnew mor1kx release in the v2 branch:
sb0hmm, no answer to my chisel question16:02
sb0"it's magic!"16:03
daliasolofk_, :)16:49
poke53282stekern: 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
poke53282In the end it will be one dumb line which I missed.17:25
poke53282stekern: I think I found it. I should not compile the musl part of the toolchain with prefix=/usr and install DESTDIR=$SYSROOT.18:03
poke53282dalias: I use the following buildscript.
poke53282look 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
poke53282TOOLCHAIN_DIR is /opt/cross/or1k-linux-musl19:16
poke53282the error happens then somewhere in toolchain_gcc2. Probably some wrong path.19:18
poke53282If I use the --prefix=/usr I compile musl like to run musl natively and install therefor into $SYSROOT.19:20
poke53282In the current (working) way, I install musl for the toolchain (especially for gcc) in the folder $(TOOLCHAIN_DIR)/or1k-linux-musl19:21
poke53282The 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
poke53282Some error in libstdc++ is responsible for this.19:23
daliasmusl doesn't even save the prefix anywhere in the output unless you're using the musl-gcc wrapper script19:28
poke53282Yes, so I think, that gcc gets confused with the directories.19:29
poke53282in both cases, musl is installed in different directories.19:30
poke53282I 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
poke53282But one time in $(TOOLCHAIN_DIR)/or1k-linux-musl  and one the time in $SYSROOT.19:31
poke53282dalias: What I can tell you is, that uclibc worked that way.19:39
poke53282btw: to install native g++ I had to add "typedef struct { char c[16]; } max_align_t;" to stddef.h19:55
poke53282I am not sure if this solved in one or the other way. But I saw the discussion on the mailing list19:56
daliasthat's definitely the wrong definition for max_align_t: it has alignment of 1 :-019:59
daliasthere's an open question about what the right definition is :/19:59
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
poke53282Ok, they mean the alignof statement.21:13
poke53282Then I would put a long double in there.21:14
poke53282instead of "char c[16]"21:14
daliasthe issue is unfortunately complex21:15
poke53282Yes, I read it.21:15
daliason the musl list? :)21:15
poke53282So, make it architecture dependent.21:16
poke53282Yes, on the musl list.21:16
poke53282but g++ requires it.21:16
poke53282in order to compile a native version21:16
daliasi'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 type21:17
daliaswe will add it21:17
daliasjust need to figure out the best solution to this21:17
poke53282double is always 8 byte?21:18
daliasit always has 8 byte size, but i386 does not have an 8-byte alignment requirement for it21:18
poke53282ignore all architectures on which this is different :)21:18
daliasthe obvious type for max_align_t is something like21:19
poke53282Ahh, Ok. but the SIMD units like SSE  for example need it aligned21:19
daliasunion { char __c[16]; long double __ld; double __d; void *__p; long long __ll; };21:19
daliasbut this yields an alignment of 4, not 8, on i38621:19
poke53282I understand21:19
daliasdespite the ABI we want to match having max_align_t with alignment of 821:20
daliasgcc achieves this in their version of stddef.h with __alignas__ or something21:20
daliasbut their semantics for __alignas__ are bogus :)21:21
daliasit uses the "preferred alignment for optimization" rather than the "natural alignment of the type"21:21
daliaslong double __alignas__(long double) __ld;21:21
daliasdoes not yield the same result as21:22
daliaslong double __ld;21:22
daliaswhich is utterly counter-intuitive and nonsensical :)21:22
daliasanyway 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
daliasi think we can simply expose max_align_t only for C11 or C++1121:23
daliasand in that cause, use _Alignas(sizeof(long double)) or similar21:23
poke53282At the moment, it looks like, that it is only used for compiling g++.21:24
poke53282I understand the problem now, but don't have any solution. Make it always 16. That should be portable for now :)21:29
poke53282Ok, probably not.21:29
poke53282Then gcc uses internal another alignment.21:30
daliaswe don't have to fix the number as a constant21:30
daliaswe just need to do something so that the alignment gets forced up to at least 821:30
daliaseven on archs where no types have alignment >421:30
daliasso maybe21:30
daliasunion { 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
poke53282something like this.21:32
poke53282Ok, all bad solutions.21:33
daliasah 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 member21:33
poke53282but why 8 for architectures? Is there some internal limitation of musl? on openrisc it should be 4 I think.21:36
daliasdoesn't or1k abi have aligned long long?21:37
poke53282Hmm, according to the table which I have in front of me, the highest alignment if 4. Even for double.21:41
poke53282For the 32 Bit architecture of course21:41
poke53282Ahh, Ok, but then the vector types.21:41
poke53282they have an alignment of 821:41
poke53282But as far as I know, they are not used.21:42
poke53282long long should also give an alignment of 4 according to specification.21:42
daliasoh? that's really unusual, but ok21:43
poke53282Page 332 in the specification21:44
daliascan you see what you get for _Alignof(max_align_t) and sizeof(max_align_t) with gcc's stddef.h ?21:44
daliascan you give me the link for that?21:44
daliasif so i think it's a rather poor design choice, but probably too late to fix21:44
daliasit makes it impossible to later add 64-bit instructions that actually need 64-bit alignment without changing the abi :(21:45
daliasindeed, alignment is 421:46
daliasi suspect max_align_t still has 8-byte alignment tho21:46
daliasbtw long double is completely missing from the table21:47
poke53282Yes, I think that means, that it is just a double.21:54
daliasyeah, i'm sure it's just double, but that should be stated21:55
daliaswith an extra line21:55
daliaslong double 8 4 Double precision float21:55
poke53282Yes, should be in there.21:55
poke53282the alignof function always returns 4 for int, long long, double and long double.21:57
daliaswhat does it return for max_align_t using the definition from gcc's stddef.h ?21:57
poke53282Ah, wait. They have there own stddef.h21:57
daliasyes gcc provides the headers for a freestanding C implementation21:58
daliasand glibc does not provide these; it relies on gcc's versions21:58
daliasthis requires them to be aware of each other's internal macros for controlling what's exposed21:58
daliasand it's really inefficient and ugly when other headers need to get the types from here21:58
dalias(multiple includes of the same header cannot be optimized out by the compiler)21:58
daliasmusl does not use gcc's headers at all21:58
daliasit provides a full set of C headers on its own21:59
dalias(this is also needed for supporting some non-gcc compilers like pcc, altho clang mimics gcc here, i think)21:59
poke53282alignof(max_align_t) => 4     sizeof(max_align_t) => 1622:04
poke53282_Alignof is not reckognized22:04
poke53282complicated stuff.22:05
poke53282My 64 bit-x86 machine tells me alignof(max_align_t) => 16 sizeof(max_align_t) => 3222:09
daliasbecause long double has size/alignment 1622:10
poke53282and whats with the AVS unit? The alignment is maybe stricter than 16.22:11
poke53282AVX unit22:11
daliasmax_align_t must have alignment >= the alignment of any fundamental type22:12
daliasand should be considered the highest alignment that's supported "in all contexts" (which is poorly defined :-p)22:13
daliasso for example malloc returns memory with at least the alignment of max_align_t22:14
daliasper the standard, max_align_t is very flexible as long as it's >= any fundamental type's alignment and <= malloc's alignment22:16
poke53282That's good to know. I always excpected this.22:16
daliasfor the purposes of defining an ABI tho, you need to choose a fixed size and alignment for max_align_t for the arch22:17
--- Log closed Sat Aug 09 00:00:56 2014

Generated by 2.15.2 by Marius Gedminas - find it at!