ibotlog2html for #crosstool-ng

<< Previous 2013-09-30 Next >>

# 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

Generated by ibotlog2html by Yann E. MORIN