| # 01:04:31 | blueness|uclibc | quits : Remote host closed the connection |
| # 02:29:28 | djerome | quits : Remote host closed the connection |
| # 04:42:11 | jevin | joins #crosstool-ng |
| # 04:43:47 | hwoarang_ | joins #crosstool-ng |
| # 04:43:47 | hwoarang_ | quits : Changing host |
| # 04:43:47 | hwoarang_ | joins #crosstool-ng |
| # 04:44:33 | tgaz_ | joins #crosstool-ng |
| # 04:49:36 | jevin_ | quits : *.net *.split |
| # 04:49:36 | hwoarang | quits : *.net *.split |
| # 04:49:36 | tgaz | quits : *.net *.split |
| # 04:49:40 | tgaz_ | is now known as: tgaz |
| # 05:37:30 | smartin_ | joins #crosstool-ng |
| # 05:55:15 | diorcety | joins #crosstool-ng |
| # 06:18:53 | falstaff | quits : Ping timeout: 245 seconds |
| # 06:22:07 | diorcety | quits : Quit: Leaving. |
| # 07:06:57 | smartin_ | quits : Quit: leaving |
| # 07:50:55 | smartin | quits : Read error: Connection reset by peer |
| # 07:52:26 | smartin | joins #crosstool-ng |
| # 08:44:59 | smartin | quits : *.net *.split |
| # 08:47:24 | smartin | joins #crosstool-ng |
| # 09:51:52 | hwoarang_ | is now known as: hwoarang |
| # 10:12:53 | codyps | quits : Ping timeout: 248 seconds |
| # 10:19:14 | codyps | joins #crosstool-ng |
| # 11:20:59 | blueness | quits : Ping timeout: 248 seconds |
| # 11:21:39 | blueness | joins #crosstool-ng |
| # 12:12:41 | alan_o | joins #crosstool-ng |
| # 12:52:41 | alan_o_ | joins #crosstool-ng |
| # 12:53:30 | alan_o | quits : Ping timeout: 264 seconds |
| # 12:53:38 | alan_o_ | is now known as: alan_o |
| # 12:57:00 | ccole | quits : Read error: Connection reset by peer |
| # 13:23:37 | alan_o_ | joins #crosstool-ng |
| # 13:24:38 | alan_o | quits : Disconnected by services |
| # 13:24:50 | alan_o_ | is now known as: alan_o |
| # 15:44:42 | doc2 | joins #crosstool-ng |
| # 15:50:23 | y_morin | joins #crosstool-ng |
| # 16:08:29 | falstaff | joins #crosstool-ng |
| # 16:30:59 | diorcety | joins #crosstool-ng |
| # 17:02:16 | y_morin | is rebuilding all the samples before the release... |
| # 17:19:18 | alan_o | quits : Ping timeout: 264 seconds |
| # 17:30:37 | alan_o | joins #crosstool-ng |
| # 18:09:09 | diorcety | y_morin: hi |
| # 18:24:06 | mnt_real | quits : Excess Flood |
| # 18:24:49 | mnt_real | joins #crosstool-ng |
| # 18:37:52 | breiker | quits : Ping timeout: 256 seconds |
| # 18:40:38 | breiker | joins #crosstool-ng |
| # 18:45:19 | breiker | quits : Ping timeout: 260 seconds |
| # 18:47:38 | breiker | joins #crosstool-ng |
| # 18:50:00 | shap | joins #crosstool-ng |
| # 18:51:24 | shap | Quick Q abount arm-unknown-eabi vs armeb-unknown-eabi. The armeb config builds successfully with no C library. The arm config does not (or at least, my attempt to do so with menuconfig fails). Am I missing something obvious that is needed to get a freestanding compiler built for arm rather than armeb? |
| # 18:51:39 | breiker | quits : Ping timeout: 240 seconds |
| # 18:53:09 | breiker | joins #crosstool-ng |
| # 18:58:04 | breiker | quits : Ping timeout: 264 seconds |
| # 19:02:40 | breiker | joins #crosstool-ng |
| # 19:07:20 | breiker | quits : Ping timeout: 256 seconds |
| # 19:09:40 | breiker | joins #crosstool-ng |
| # 19:14:15 | breiker | quits : Ping timeout: 260 seconds |
| # 19:15:41 | breiker | joins #crosstool-ng |
| # 19:19:52 | breiker | quits : Ping timeout: 246 seconds |
| # 19:22:12 | breiker | joins #crosstool-ng |
| # 19:26:52 | breiker | quits : Ping timeout: 264 seconds |
| # 19:28:42 | breiker | joins #crosstool-ng |
| # 19:34:07 | shap | Oh. Never mind. The problem appears to be that in the absence of a C library you can't build the C++ compiler, because the libiberty build relies on headers from the C library. Is that it? And if so, shouldn't the BARE_METAL check in cc.in be extended to wrap the CXX case as well? |
| # 19:35:40 | breiker | quits : Ping timeout: 256 seconds |
| # 19:37:43 | breiker | joins #crosstool-ng |
| # 19:42:15 | breiker | quits : Ping timeout: 260 seconds |
| # 19:43:14 | breiker | joins #crosstool-ng |
| # 19:49:47 | breiker | quits : Ping timeout: 248 seconds |
| # 19:50:45 | breiker | joins #crosstool-ng |
| # 19:52:20 | y_morin | shap: Maybe have languages depend on !CT_LIBC_none instead of !BARE_METAL ? |
| # 19:52:27 | y_morin | diorcety: Howdy? |
| # 19:54:03 | shap | y_morin: It's been a while since I've dug into this, but I just dug back through some bug reports, and here's what I think is going on. |
| # 19:55:19 | shap | G++ builds liberty for the demangler. This is used on the build machine, not the target machine. It was a long-standing bug in the makefiles for a while that libiberty was getting built for the target and should not have been. So I think that's part of the problem here. |
| # 19:56:03 | y_morin | shap: So, bug in gcc, not ct-ng? I like that! :-) |
| # 19:56:13 | shap | The bigger issue, however, is libstdc++. In contrast to C, C++ has a surprising amount of runtime dependency, and it's nearly impossible to build libstdc++ in a freestanding way (or, at least, I've never managed it). |
| # 19:56:26 | y_morin | shap: what can we do to work this around? |
| # 19:56:40 | shap | y_morin: well, I think so, but because of the libstdc++ issue, it may be one of those bugs that nobody thinks is worth the bother to fix. |
| # 19:57:02 | shap | y_morin: do you know of any platform that builds a standalone G++ successfully? |
| # 19:57:13 | shap | y_morin: excuse me. Freestanding. |
| # 19:57:52 | y_morin | shap: nope. And I'm definitely in that don't-bother camp, as I don't really use it. |
| # 19:58:04 | breiker | quits : Ping timeout: 264 seconds |
| # 19:58:45 | y_morin | shap: OTOH, if the fix is simple, I won't be against having it. But preferrably as a workaround in ct-ng rather than a patch to gcc. |
| # 19:58:46 | breiker | joins #crosstool-ng |
| # 19:59:37 | shap | You don't really need libstdc++ as a whole, but you definitely need some early runtime stuff. Without it, you don't get RTTI, stack unwind for exceptions, or new/delete (because they can raise exceptions). I think the libiberty part of the problem is easy to fix. Not so convinced about the rest. |
| # 20:00:50 | shap | Yeah, it's all coming back to me in a wave of nausea. Look here http://wiki.osdev.org/Bare_Bones#Freestanding_and_Hosted_Environments under "Writing a kernel in C++" |
| # 20:01:32 | shap | If you disable exceptions and rtti, it sorta limps along. Problem is that you're now in a very compiler-specific place, and you're no longer working in C++, really. |
| # 20:01:54 | shap | This is part of why we moved back to C when we went from the EROS operating system to Coyotos. Also because of other overheads. |
| # 20:02:34 | shap | OK. new question. Is coldfire support handled by the m68k target, or should I go in and add it? |
| # 20:07:05 | y_morin | 21 samples tested so far; 7 broken (1 already fixed, 4 for known, easily fixable reasons, 2 for non-obvious reasons); 23 samples to test... |
| # 20:07:45 | y_morin | thinks the release won't be on time (well, it already slipped 5 months...) |
| # 20:07:53 | y_morin | shap: Hold-on, checking... |
| # 20:09:41 | y_morin | shap: From gcc's man page: M680x0 Options These are the -m options defined for M680x0 and ColdFire processors. |
| # 20:10:00 | y_morin | shap: So, for gcc, coldfire is a m68k. |
| # 20:10:18 | y_morin | shap: Now, that it works in ct-ng is another issue! Testers wanted! ;-) |
| # 20:11:01 | y_morin | s/that/whether/ |
| # 20:11:40 | y_morin | ctngbot is alive! :-) |
| # 20:12:28 | shap | y_morin: Heh. Hey, thanks for such prompt answers. Wouldn't it be nice if all this stuff was simple? :-) |
| # 20:14:32 | y_morin | shap: If those things were simple, we would not be discussing them right now. Which would be a shame! :-) |
| # 20:14:57 | y_morin | would then have time to dedicate to toher projects! :-) |
| # 20:17:06 | shap | y_morin: heh. I spent years maintaining a RPM repository for my clients so that updates to the cross tools would propagate. Surprising how much that helped for certain classes of embedded customers. But it's definitely a black art, and especially so if the OS is not a UNIX derivative. |
| # 20:36:29 | shap | y_morin: Oh. There was one other thing. |
| # 20:39:04 | y_morin | shap: ? |
| # 20:39:12 | shap | A lot of deeply embedded systems end up using something like FreeRTOS and then use newlib with dummied-out system calls. The catch with this is that the use of newlib is now multithreaded. A bit of support is needed in newlib to fetch the appropriate _reent structure, and then you need to compile newlib with appropriate options to enable threading. It looks like crosstool-ng doesn't address this? |
| # 20:39:57 | shap | It caught my attention because with newer SoCs the problem is even worse now because of dual-core, and compiling newlib without thread support on those machines is downright broken. |
| # 20:40:03 | shap | So what's the status and intentions in this regard? |
| # 20:40:19 | shap | Mind you I'm happy to help - just don't want to go haring off into the wilderness. |
| # 20:40:47 | y_morin | shap: There's LIBC_NEWLIB_EXTRA_CONFIG_ARRAY to pass extra ./configure args. |
| # 20:40:58 | y_morin | shap: That can be turned into a new option, though. |
| # 20:42:29 | shap | Yeah, I saw that. The bigger issue is the need for a target-specific patch to newlib to add support for fetching the reent structure. FreeRTOS (as an example) doesn't have any convention I know about for fetching the per-thread state structure, so there's no general way to do it. |
| # 20:42:56 | shap | If I'm building with ct-ng, is there an accepted way to provide a user-defined patch, or does that step past the line of what you are trying to do with this tool? |
| # 20:44:40 | y_morin | shap: The line is a bit blurry. I think it is a bit far-fetched for ct-ng. |
| # 20:44:56 | y_morin | shap: However, you can instruct ct-ng to use a custom patchset. |
| # 20:45:11 | y_morin | shap: Or a local (aka custom) tree for newlib. |
| # 20:46:09 | shap | If FreeRTOS had a convention for how to implement thread-specific data, it might be worth adding it to the list of OS's (and similarly for other popular choices) and supplying the relevant patch to newlib (if needed) once. |
| # 20:46:30 | breiker | quits : Ping timeout: 256 seconds |
| # 20:47:09 | shap | Here's my concern: I suspect a lot of ct-ng users don't understand the runtime guts here - that's why they are using ct-ng. They build (e.g.) newlib expecting it to "just work", and on a multicore (e.g. LPC43xx) or multithread system it won't. |
| # 20:47:29 | shap | If it's a lot of trouble, then the issue should probably be left alone, but it may not be. |
| # 20:47:49 | y_morin | shap: Why not push this upstream to newlib? |
| # 20:47:52 | breiker | joins #crosstool-ng |
| # 20:49:18 | shap | Ultimately, it should go upstream to newlib, but ct-ng would still need to know about a new target OS. I was thinking to poke at it locally and see how far I could get. OTOH I think anybody who uses libc for a deeply embedded target needs their head examined, so it may not be worth the bother. :-) |
| # 20:50:38 | y_morin | shap: If you can make it slim and slick, then why not. ;-) |
| # 20:51:02 | shap | My main thought here is that with multicore on the rise, it's going to be a progressively more common source of mistakes by well-intentioned ct-ng users. |
| # 20:51:14 | shap | And unlike C++, multicore isn't going away. :-) |
| # 20:51:43 | y_morin | shap: OTOH, I doubt bare-metal to be the most common case for multicore. |
| # 20:51:44 | shap | How's that for optimism. ;-) |
| # 20:52:12 | y_morin | shap: In such a scenario, you probably want a real OS on there. ;-) |
| # 20:52:16 | y_morin | hides... |
| # 20:52:18 | shap | y_morin: How many Cortex-M's do you know of that run linux? No MMU there, so bare metal is the only choice that ct-ng supports. |
| # 20:52:35 | shap | y_morin: well, yeah, but if you want a real OS you can't run linux anyway. ;-) |
| # 20:53:03 | y_morin | shap: I though Linux could run on noMMU... |
| # 20:53:22 | shap | But jokes aside, I'm thinking here about multicore Cortex-M variants. And yes, I agree you need some form of OS or executive, which is why I was talking about FreeRTOS. |
| # 20:53:41 | y_morin | shap: IIRC, there are patches floating around (on the LAKML?) adding cortex-M support to Linux. |
| # 20:53:56 | y_morin | shap: Yes, granted. |
| # 20:54:16 | y_morin | shap: Jokes apart, yes, a new "Target OS" in ct-ng could be added. |
| # 20:54:55 | y_morin | shap: But I'd like it to be minimal, eg. does not require heavy patching (if at all) to gcc/newlib/binutils. |
| # 20:55:00 | shap | y_morin: I haven't looked at whether linux runs noMMU. Hard to imagine that I'd want to lug around that much code for that purpose. Most of the deeply embed people I've talked to seem to gravitate toward FreeRTOS - at least until they discover that it doesn't come with net support. Then they go wandering all over. |
| # 20:55:11 | y_morin | shap: if support is upstream, then good, Otherwise, push support there first. |
| # 20:56:40 | shap | y_morin: concur about patching. In GCC the only issue should be base addresses, which is inherently target dependent and is mostly just a linker script issue. The rest should mostly be upstream once it's stable, and then just getting the right configure options supported in ct-ng. |
| # 20:56:50 | y_morin | imagine people running round in panic, flailing arms around, screaming "No network! No network! The end is nigh!" |
| # 20:57:00 | shap | As an interim matter, though, I'll likely want to maintain some newlib patches locally. |
| # 20:57:13 | shap | y_morin: Well, ya know, they get all confused when the token falls out of the ethernet. |
| # 20:57:53 | y_morin | lol! |
| # 20:58:43 | y_morin | shap: bonus point for talking "token" and "ethernet" in the same sentence! :-) |
| # 20:59:40 | shap | OK. I think the config issue is mainly that glib option depends on linux/unix, eglibc option depends on MMU, and for any other OS you need to get the right target tuple specified in the configure invocation for newlib. Might need some config.target changes in various places that would eventually go upstream (if they aren't already present). |
| # 20:59:55 | shap | y_morin: can't take credit. Very old dilbert cartoon. |
| # 21:01:35 | breiker | quits : Ping timeout: 260 seconds |
| # 21:02:23 | shap | Here it is: http://search.dilbert.com/comic/Token%20Ring |
| # 21:03:23 | breiker | joins #crosstool-ng |
| # 21:03:25 | shap | OK. Thanks again. AFK. |
| # 21:03:31 | y_morin | shap see ya! |
| # 21:18:48 | breiker | quits : Ping timeout: 252 seconds |
| # 21:19:02 | smartin_ | joins #crosstool-ng |
| # 21:19:55 | breiker | joins #crosstool-ng |
| # 21:33:48 | doc2 | quits : Remote host closed the connection |
| # 21:34:48 | y_morin | quits : Quit: Nighty Night! |
| # 21:47:34 | shap | y_morin: Addendum to previous. Looks like people have dealt with FreeRTOS/newlib before. It takes a couple of lines hacked into FreeRTOS and then the appropriate configure option to newlib. Let me confirm that it all works, and then I can send you unified diff for the kconfig stuff. |
| # 21:48:31 | shap | y_morin: basically, I think we need to add a new threading model LIBC_SUPPORT_THREADS_NEWLIB (and possibly NEWLIB_DYNAMIC as well), and then pass the appropriate option to the newlib configure line. |
| # 21:49:46 | shap | y_morin: if that is done, then what remains is to make the appropriate change in the context switch code of the threading executive. For single core that's all - newlib has a global variable for just this purpose. For multicore that variable needs to be CPU-specific, and I need to look in to how that works on a couple of different multicores in order to decide how to handle it. |
| # 21:50:19 | shap | y_morin: but if I'm reading this right, I should be able to send you a patch and a page with instructions on how to mod FreeRTOS to do the right thing, at least for single core. |
| # 21:52:26 | shap | AFK again for a bit. |
| # 22:08:13 | shap-ipad | joins #crosstool-ng |
| # 22:11:58 | shap-ipad | quits : Client Quit |
| # 22:24:28 | breiker | quits : Ping timeout: 264 seconds |
| # 22:27:03 | breiker | joins #crosstool-ng |
| # 22:48:25 | smartin_ | quits : Quit: leaving |
| # 23:13:35 | shap | quits : Quit: shap |