| # 00:31:55 | blueness | quits : Quit: blueness |
| # 00:43:47 | fenugrec | quits : Read error: Connection reset by peer |
| # 00:44:04 | fenugrec | joins #crosstool-ng |
| # 01:02:28 | fenugrec | Hi, how much swearing should I expect to do, to setup a gcc toolchain targetting the SuperH architecture (specifically for freestanding / baremetal embedded applications) ? |
| # 01:03:18 | fenugrec | quits : Remote host closed the connection |
| # 01:03:39 | fenugrec | joins #crosstool-ng |
| # 02:17:52 | aneyman__ | probably not too much from ct-ng - there is a example targeting sh4 |
| # 02:18:24 | aneyman__ | not using superh myself, though, so I have no idea whether there are any binutils/gcc bugs lurking |
| # 02:20:49 | fenugrec | aneyman__ ah yes I hadn't looked well enough in the samples/ dir. I'm still fuzzy on what I'll need to change to get the particular output I want... I want a special flavor of "freestanding" code |
| # 02:26:41 | aneyman__ | well, that should present even less challenge |
| # 02:27:11 | aneyman__ | take the example and change c library to none |
| # 02:27:27 | aneyman__ | what is the *special* flavor, btw? |
| # 02:30:59 | fenugrec | aneyman__ well, it will be loaded + executed in RAM, and space is extremely limited; so I want relocatable code ('easy' -fpie / PIE / PIC, need to read into the differences). I'm not sure if I will have to write my own "loader" to fill in the .idata and .bss sections - or indeed, do without .idata altogether since everything is in RAM |
| # 02:43:11 | aneyman__ | sorry, I am not familiar with SuperH specifics - I thought the special flavor is somethin architecture-neutral |
| # 02:43:29 | aneyman__ | but then again, if gcc/ld can do that, ct-ng shouldn't get in the way |
| # 02:45:40 | fenugrec | you're probably right - I'm not sure of the boundaries are between what gcc handles (+ 'spec' files) and ld |
| # 02:49:15 | fenugrec | and also where "crt0" comes in. I know exactly what the output needs to look like, but not sure how to get the toolchain to do my bidding with minimal fuss : ) |
| # 03:11:29 | aneyman__ | well, again, I am not a superH expert, so from a general point of view: what you describe looks achievable with linker scripts; I am not sure why you need relocatable code on bare metal - for PIE/PIC to make sense, there must be some agent that loads the binaries at runtime-determined address - and baremetal implies OS kernel-type binaries, which are usually loaded at a fixed address. PIC/PIE add some code overhead due to reservation of a regist |
| # 03:11:29 | aneyman__ | er for GOT which needs to be saved/restored in function prologues/epilogues - and it makes less registers for use by the compiler, which may result in extra saves/restores of other registers |
| # 03:11:59 | aneyman__ | so if memory is at a premium, you might actually want to avoid PIC/PIE :) |
| # 03:15:16 | fenugrec | aah, bad choice of words perhap vs "relocatable", but I definitely want the code to be independant of the actual address it's loaded at. It's actually a kernel that should be able to run wherever it has been loaded. My naive assumption is that since SH has many instructions that operate relative to the program counter, there would be very minimal overhead |
| # 03:19:50 | fenugrec | for initialized data :literal pools are easy, gcc already does this very well. For branching / calling, the relative bra / bsr instructions have only a +/- 1kB range, but it's easy enough to copy the PC to a general register, add a 32-bit offset, and use that general register as branch/call destination. That's how I would do it manually, in assembly, but I fear it probably doesn't fit with how gcc works - I only have a vague idea of what "GOT" means |
| # 03:26:51 | fenugrec | quits : Remote host closed the connection |
| # 03:27:11 | fenugrec | joins #crosstool-ng |
| # 03:28:32 | fenugrec | aneyman__ aarg... "-fpic : [...] Such code accesses all constant addresses through a global offset table (GOT) " |
| # 03:29:08 | fenugrec | and -fpie means that the linker goes over and does the "fixup" on every offset, I guess. |
| # 04:02:21 | fenugrec | quits : Ping timeout: 268 seconds |
| # 04:40:39 | blueness | joins #crosstool-ng |
| # 07:12:31 | blueness | quits : Quit: blueness |
| # 07:29:02 | diorcety | joins #crosstool-ng |
| # 07:53:57 | blueness | joins #crosstool-ng |
| # 11:06:03 | blueness_ | quits : Ping timeout: 244 seconds |
| # 11:06:42 | blueness | quits : Ping timeout: 260 seconds |
| # 12:12:16 | blueness | joins #crosstool-ng |
| # 12:16:04 | blueness | quits : Excess Flood |
| # 12:16:35 | blueness | joins #crosstool-ng |
| # 12:28:27 | blueness_ | joins #crosstool-ng |
| # 12:32:26 | blueness__ | joins #crosstool-ng |
| # 12:34:34 | blueness_ | quits : Ping timeout: 260 seconds |
| # 13:38:03 | blueness__ | quits : Ping timeout: 240 seconds |
| # 13:38:36 | blueness_ | joins #crosstool-ng |
| # 14:15:49 | fenug_ | joins #crosstool-ng |
| # 14:33:03 | fenug_ | is now known as: fenugrec |
| # 15:24:35 | blueness_ | quits : Quit: blueness_ |
| # 15:26:00 | blueness_ | joins #crosstool-ng |
| # 17:09:10 | y_morin | joins #crosstool-ng |
| # 17:15:16 | imMute | quits : Remote host closed the connection |
| # 17:18:06 | imMute | joins #crosstool-ng |
| # 19:24:07 | fenugrec | quits : Remote host closed the connection |
| # 19:24:26 | fenugrec | joins #crosstool-ng |
| # 20:24:56 | diorcety | quits : Read error: Connection reset by peer |
| # 20:34:08 | fenugrec | quits : Remote host closed the connection |
| # 20:34:29 | fenugrec | joins #crosstool-ng |
| # 21:56:43 | fenugrec | quits : Remote host closed the connection |
| # 21:56:59 | fenugrec | joins #crosstool-ng |
| # 21:58:43 | fenugrec | quits : Remote host closed the connection |
| # 21:59:04 | fenugrec | joins #crosstool-ng |
| # 22:48:22 | y_morin | quits : Quit: Nighty Night! |
| # 22:49:06 | luc4 | joins #crosstool-ng |
| # 22:52:47 | fenugrec | quits : Remote host closed the connection |
| # 22:53:06 | fenugrec | joins #crosstool-ng |
| # 23:06:20 | fenugrec | quits : Read error: Connection reset by peer |
| # 23:06:41 | fenugrec | joins #crosstool-ng |
| # 23:08:52 | fenugrec | quits : Remote host closed the connection |
| # 23:09:13 | fenugrec | joins #crosstool-ng |
| # 23:11:24 | fenugrec | quits : Remote host closed the connection |
| # 23:11:43 | fenugrec | joins #crosstool-ng |
| # 23:13:27 | fenugrec | quits : Remote host closed the connection |
| # 23:13:49 | fenugrec | joins #crosstool-ng |
| # 23:15:30 | fenugrec | quits : Remote host closed the connection |
| # 23:15:48 | fenugrec | joins #crosstool-ng |
| # 23:17:34 | fenugrec | quits : Remote host closed the connection |
| # 23:17:52 | fenugrec | joins #crosstool-ng |
| # 23:19:37 | fenugrec | quits : Remote host closed the connection |
| # 23:19:57 | fenugrec | joins #crosstool-ng |
| # 23:21:41 | fenugrec | quits : Remote host closed the connection |
| # 23:22:00 | fenugrec | joins #crosstool-ng |
| # 23:23:46 | fenugrec | quits : Remote host closed the connection |
| # 23:24:07 | fenugrec | joins #crosstool-ng |
| # 23:25:50 | fenugrec | quits : Remote host closed the connection |
| # 23:26:11 | fenugrec | joins #crosstool-ng |
| # 23:28:24 | fenugrec | quits : Remote host closed the connection |
| # 23:28:45 | fenugrec | joins #crosstool-ng |
| # 23:31:28 | fenugrec | quits : Remote host closed the connection |
| # 23:31:49 | fenugrec | joins #crosstool-ng |
| # 23:34:30 | fenugrec | quits : Remote host closed the connection |
| # 23:34:49 | fenugrec | joins #crosstool-ng |
| # 23:37:02 | fenugrec | quits : Remote host closed the connection |
| # 23:37:20 | fenugrec | joins #crosstool-ng |
| # 23:39:34 | fenugrec | quits : Remote host closed the connection |
| # 23:39:55 | fenugrec | joins #crosstool-ng |
| # 23:41:35 | fenugrec | quits : Remote host closed the connection |
| # 23:41:53 | fenugrec | joins #crosstool-ng |