Menu
▾
▴
linuxsh-dev
|
From: Paul M. <le...@li...> - 2002-12-22 19:56:39
|
Hi, Running into a bit of weirdness, and was curious if anyone had seen this before. I'm presently running on an SH-4, with the MMU implicitly turned off (and CONFIG_MMU unset). I've taken care of dealing with paging_init() changes, tlb ops, etc. to deal with the lack of an MMU, and none of that appears to be an issue. My current problem is that the minute init tries to start, I get endless unaligned userspace access traps. If I implicitly flush the cache prior to turning the MMU off, I don't have this problem, instead it runs into a sort of livelock situation where init just hangs .. though I'm still able to ping the target. Flushing the tlb prior to turning the MMU off for added sanity doesn't seem to make a difference one way or the other. Also, flushing the cache at context switch time (to work around potential aliasing issues, SH is VIPT) doesn't seem to make a difference here either. I haven't tried running uncached yet, though I doubt that's an issue here. Anyone seen this kind of behavior before? Suggestions? Regards, -- Paul Mundt <le...@li...> |
|
From: David M. <da...@sn...> - 2003-01-06 01:28:38
|
Jivin Paul Mundt lays it down ... > Hi, > > Running into a bit of weirdness, and was curious if anyone had seen this > before. > > I'm presently running on an SH-4, with the MMU implicitly turned off > (and CONFIG_MMU unset). I've taken care of dealing with paging_init() > changes, tlb ops, etc. to deal with the lack of an MMU, and none of that > appears to be an issue. > > My current problem is that the minute init tries to start, I get endless > unaligned userspace access traps. If I implicitly flush the cache prior > to turning the MMU off, I don't have this problem, instead it runs into > a sort of livelock situation where init just hangs .. though I'm still > able to ping the target. Flushing the tlb prior to turning the MMU off > for added sanity doesn't seem to make a difference one way or the other. > > Also, flushing the cache at context switch time (to work around > potential aliasing issues, SH is VIPT) doesn't seem to make a difference > here either. I haven't tried running uncached yet, though I doubt that's > an issue here. > > Anyone seen this kind of behavior before? Suggestions? I suspect that you are still running ELF programs. When you turn off the MMU support in the kernel, the rules for applications change a little. They cannot be paged in for example, and they have to be loaded (and relocated) at run time. Normal elf programs are loaded at a fixed addresses and this cannot work without an MMU. The uClinux guys use a program called elf2flt (ELF to flat) to make flat binaries that can be run without an MMU. You can find it at: http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/ I don't believe there is SH support in it at the moment, but it isn't a huge amount of work. Generally only a few relocation types need to be handled, Cheers, Davidm -- David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com da...@sn... Fx: +61 7 3891 3630 Custom Embedded Solutions + Security |
|
From: Paul M. <le...@li...> - 2003-01-06 19:58:45
|
On Sun, 2003-01-05 at 20:34, David McCullough wrote: > I suspect that you are still running ELF programs. When you turn off the > MMU support in the kernel, the rules for applications change a little. > They cannot be paged in for example, and they have to be loaded (and > relocated) at run time. Normal elf programs are loaded at a fixed > addresses and this cannot work without an MMU. > > The uClinux guys use a program called elf2flt (ELF to flat) to make flat > binaries that can be run without an MMU. You can find it at: > Okay, one issue with elf2flt. I've built a static busybox linked against uClibc (which was built w/o HAS_MMU set), also using the sh-uclibc- toolchain (which is also built w/o HAS_MMU). Now, this busybox itself doesn't have any relocations in it, though it's still an ELF. elf2flt currently bails and refuses to write the flt hdr/file if it sees that the ELF doesn't have anything needing relocation. This happens around line 900 of elf2flt.c from current HEAD by way of the bfd_get_file_flags() HAS_RELOC check. If I comment this out, the flt file is generated properly. This brings up the question, if I have an ELF that was built with PIC turned off, can binfmt_elf deal with it? or does it still have to pass through binfmt_flat? > http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/ > > I don't believe there is SH support in it at the moment, but it isn't a > huge amount of work. Generally only a few relocation types need to be > handled, Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC supported. I'll submit patches for this once the above mess is worked out. Regards, -- Paul Mundt <le...@li...> |
|
From: David M. <da...@sn...> - 2003-01-06 21:59:35
|
Jivin Paul Mundt lays it down ... > On Sun, 2003-01-05 at 20:34, David McCullough wrote: > > I suspect that you are still running ELF programs. When you turn off the > > MMU support in the kernel, the rules for applications change a little. > > They cannot be paged in for example, and they have to be loaded (and > > relocated) at run time. Normal elf programs are loaded at a fixed > > addresses and this cannot work without an MMU. > > > > The uClinux guys use a program called elf2flt (ELF to flat) to make flat > > binaries that can be run without an MMU. You can find it at: > > Okay, one issue with elf2flt. I've built a static busybox linked against > uClibc (which was built w/o HAS_MMU set), also using the sh-uclibc- > toolchain (which is also built w/o HAS_MMU). Now, this busybox itself > doesn't have any relocations in it, though it's still an ELF. Ok, I guess it's a possibility that on SH you can generate an executable that doesn't need relocations, but I would be suspicious, especially if it isn't built with PIC. It sounds like elf2flt is not being used correctly as all the SH code I have seen generated would need relocations to run on a non-MMU system. > elf2flt currently bails and refuses to write the flt hdr/file if it sees > that the ELF doesn't have anything needing relocation. This happens > around line 900 of elf2flt.c from current HEAD by way of the > bfd_get_file_flags() HAS_RELOC check. If I comment this out, the flt > file is generated properly. > > This brings up the question, if I have an ELF that was built with PIC > turned off, can binfmt_elf deal with it? or does it still have to pass > through binfmt_flat? binfmt_elf will deal with it, but the program will not run. You would have to link every application at a different address and then make sure that you never ran more than one instance of each. Even then I doubt it would work. You will need to use flat executables to get it going. > > http://cvs.uclinux.org/cgi-bin/cvsweb/elf2flt/ > > > > I don't believe there is SH support in it at the moment, but it isn't a > > huge amount of work. Generally only a few relocation types need to be > > handled, > > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC > supported. I'll submit patches for this once the above mess is worked > out. Sounds good. By the way, I subscribed to linuxsh-dev a month or so ago and haven't seen any traffic. It is working or am I missing something ? Cheers, Davidm -- David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com da...@sn... Fx: +61 7 3891 3630 Custom Embedded Solutions + Security |
|
From: Paul M. <le...@li...> - 2003-01-06 22:19:43
|
On Mon, 2003-01-06 at 17:06, David McCullough wrote: > Ok, I guess it's a possibility that on SH you can generate an executable > that doesn't need relocations, but I would be suspicious, especially if > it isn't built with PIC. It sounds like elf2flt is not being used > correctly as all the SH code I have seen generated would need relocations > to run on a non-MMU system. > I don't think its a matter of elf2flt not being used correctly, since I can use a cross-compiled read-elf to look at the ELF and it also reports this. Ie: ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Hitachi SH Version: 0x1 Entry point address: 0x4000c0 Start of program headers: 52 (bytes into file) Start of section headers: 246920 (bytes into file) Flags: 0x9 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 14 Section header string table index: 13 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .init PROGBITS 00400074 000074 00003c 00 AX 0 0 4 [ 2] .text PROGBITS 004000c0 0000c0 031260 00 AX 0 0 32 [ 3] .fini PROGBITS 00431320 031320 000030 00 AX 0 0 4 [ 4] .rodata PROGBITS 00431350 031350 00a2e4 00 A 0 0 4 [ 5] .data PROGBITS 0044b634 03b634 000a10 00 WA 0 0 4 [ 6] .eh_frame PROGBITS 0044c044 03c044 000004 00 WA 0 0 4 [ 7] .ctors PROGBITS 0044c048 03c048 000008 00 WA 0 0 4 [ 8] .dtors PROGBITS 0044c050 03c050 000008 00 WA 0 0 4 [ 9] .jcr PROGBITS 0044c058 03c058 000004 00 WA 0 0 4 [10] .got PROGBITS 0044c05c 03c05c 0003d4 04 WA 0 0 4 [11] .sbss PROGBITS 0044c430 03c430 000000 00 W 0 0 1 [12] .bss NOBITS 0044c430 03c430 00482c 00 WA 0 0 4 [13] .shstrtab STRTAB 00000000 03c430 000058 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00400000 0x00400000 0x3b634 0x3b634 R E 0x10000 LOAD 0x03b634 0x0044b634 0x0044b634 0x00dfc 0x05628 RW 0x10000 Section to Segment mapping: Segment Sections... 00 .init .text .fini .rodata 01 .data .eh_frame .ctors .dtors .jcr .got .bss There is no dynamic segment in this file. There are no relocations in this file. There are no unwind sections in this file. No version information found in this file. That's just limited to this particular application. If I look at another SH bin, there's quite a bit of relocation, but that's mostly limited to R_SH_COPY, R_SH_JMP_SLOT and R_SH_GLOB_DAT. > binfmt_elf will deal with it, but the program will not run. You would > have to link every application at a different address and then make sure > that you never ran more than one instance of each. Even then I doubt it > would work. You will need to use flat executables to get it going. > Okay, so by this assumption, elf2flt should _still_ convert the bin even if there aren't any relocations to speak of? In that case, its current behavior is broken. > > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC > > supported. I'll submit patches for this once the above mess is worked > > out. > > Sounds good. > > By the way, I subscribed to linuxsh-dev a month or so ago and haven't seen > any traffic. It is working or am I missing something ? > This is a dangerous combination of SourceForge thinking and there being low traffic in general. Though if you're seeing this mail and the one before it, you're likely seeing traffic from there, since uclinux-dev doesn't seem to like me sending it mail. I have still to convince mailman on SF that I can send it mail, being subscribed and all... SF idiocies (to which there is an incredible abundance) usually work themselves out given some time. You may also wish to look at the list archives (if they're working yet, see note about SF idiocies in preceding paragraph) to see if there's anything you've missed. Regards, -- Paul Mundt <le...@li...> |
|
From: David M. <da...@sn...> - 2003-01-07 01:09:09
|
Jivin Paul Mundt lays it down ... > On Mon, 2003-01-06 at 17:06, David McCullough wrote: > > Ok, I guess it's a possibility that on SH you can generate an executable > > that doesn't need relocations, but I would be suspicious, especially if > > it isn't built with PIC. It sounds like elf2flt is not being used > > correctly as all the SH code I have seen generated would need relocations > > to run on a non-MMU system. > > > I don't think its a matter of elf2flt not being used correctly, since I > can use a cross-compiled read-elf to look at the ELF and it also reports > this. Ie: elf2flt is not run on the final executable file. Executable files for the most part do not have relocations, they are all resolved during the link stage. elf2flt runs on a relocatable version of the executable (not quite fully linked) so that it can find all the parts of the program that will actually need relocating in a non-MMU environment. The ld-elf2flt script that comes with elf2flt is generally used to replace the linker so it can intercept the -elf2flt flag on the link line and take the appropriate actions on the files as required. The linker is renamed ld.real and ld-elf2flt calls this. I am not 100% on how this is handled by the uClibc cross tools. I think ld-elf2flt has been moved into 'C' code somewhere. > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: Hitachi SH > Version: 0x1 > Entry point address: 0x4000c0 > Start of program headers: 52 (bytes into file) > Start of section headers: 246920 (bytes into file) > Flags: 0x9 > Size of this header: 52 (bytes) > Size of program headers: 32 (bytes) > Number of program headers: 2 > Size of section headers: 40 (bytes) > Number of section headers: 14 > Section header string table index: 13 > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg > Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 > 0 0 0 > [ 1] .init PROGBITS 00400074 000074 00003c 00 AX > 0 0 4 > [ 2] .text PROGBITS 004000c0 0000c0 031260 00 AX > 0 0 32 > [ 3] .fini PROGBITS 00431320 031320 000030 00 AX > 0 0 4 > [ 4] .rodata PROGBITS 00431350 031350 00a2e4 00 A > 0 0 4 > [ 5] .data PROGBITS 0044b634 03b634 000a10 00 WA > 0 0 4 > [ 6] .eh_frame PROGBITS 0044c044 03c044 000004 00 WA > 0 0 4 > [ 7] .ctors PROGBITS 0044c048 03c048 000008 00 WA > 0 0 4 > [ 8] .dtors PROGBITS 0044c050 03c050 000008 00 WA > 0 0 4 > [ 9] .jcr PROGBITS 0044c058 03c058 000004 00 WA > 0 0 4 > [10] .got PROGBITS 0044c05c 03c05c 0003d4 04 WA > 0 0 4 > [11] .sbss PROGBITS 0044c430 03c430 000000 00 W > 0 0 1 > [12] .bss NOBITS 0044c430 03c430 00482c 00 WA > 0 0 4 > [13] .shstrtab STRTAB 00000000 03c430 000058 00 > 0 0 1 > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings) > I (info), L (link order), G (group), x (unknown) > O (extra OS processing required) o (OS specific), p (processor > specific) > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg > Align > LOAD 0x000000 0x00400000 0x00400000 0x3b634 0x3b634 R E > 0x10000 > LOAD 0x03b634 0x0044b634 0x0044b634 0x00dfc 0x05628 RW > 0x10000 > > Section to Segment mapping: > Segment Sections... > 00 .init .text .fini .rodata > 01 .data .eh_frame .ctors .dtors .jcr .got .bss > > There is no dynamic segment in this file. > > There are no relocations in this file. > > There are no unwind sections in this file. > > No version information found in this file. > > That's just limited to this particular application. If I look at another > SH bin, there's quite a bit of relocation, but that's mostly limited to > R_SH_COPY, R_SH_JMP_SLOT and R_SH_GLOB_DAT. All of the above looks like information from the final executable for the file. You need to try and get you hands on the temporary file that ld-elf2flt (or it's equivalent) creates. It is called XXX.elf and if it doesn't have any relocations then you do indeed have a file with no relocations. > > binfmt_elf will deal with it, but the program will not run. You would > > have to link every application at a different address and then make sure > > that you never ran more than one instance of each. Even then I doubt it > > would work. You will need to use flat executables to get it going. > > Okay, so by this assumption, elf2flt should _still_ convert the bin even > if there aren't any relocations to speak of? In that case, its current > behavior is broken. I'm still not convinced but, if you don't need relocations for SH then remove the test for SH platforms. This check is merely a safety check as on all the platforms currently supported, the absence of relocations signals broken apps or incorrect use of elf2flt. This was of more importance in the past when developers used to run elf2flt by hand and often got it wrong ;-) You can double check the need for relocations by looking at the output of sh-linux-objdump -D XX.elf. It will be obvious from the asm if it actually needs relocations. There will be absolute addresses in the code. Any absolute address used for a branch, function call or data access will need a relocation in the flat file to work in a non-MMU environment. > > > Currently I have R_SH_DIR32, R_SH_REL32, R_SH_GOT32 and R_SH_GOTPC > > > supported. I'll submit patches for this once the above mess is worked > > > out. > > > > Sounds good. > > > > By the way, I subscribed to linuxsh-dev a month or so ago and haven't seen > > any traffic. It is working or am I missing something ? > > This is a dangerous combination of SourceForge thinking and there being > low traffic in general. Though if you're seeing this mail and the one > before it, you're likely seeing traffic from there, since uclinux-dev > doesn't seem to like me sending it mail. > > I have still to convince mailman on SF that I can send it mail, being > subscribed and all... SF idiocies (to which there is an incredible > abundance) usually work themselves out given some time. > > You may also wish to look at the list archives (if they're working yet, > see note about SF idiocies in preceding paragraph) to see if there's > anything you've missed. Ok, it suddenly seems to be working. I received two copies of my last reply, but only one for the original message ?? uclinux-dev will not let you post unless you are subscribed IIRC, Cheers, Davidm -- David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com da...@sn... Fx: +61 7 3891 3630 Custom Embedded Solutions + Security |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X