This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: page size change on MIPS


Hi All,

I debug this issue further, I check in kernel  File name is
binfmt_elf.c and function name is  create_elf_tables()

I put a debug print here to check what kernel is reading from user space.

		if (__put_user((elf_addr_t)p, argv++))
			return -EFAULT;
		len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
		printk("\n Lenght of arg=%ld,%s \n",len,(void __user *)p);
		if (!len || len > MAX_ARG_STRLEN)
			return -EINVAL;
		p += len;
	}


when Page size is 16KB  o/p is

Lenght of arg=6,/init

when Page size is 64KB  o/p is

Lenght of arg=1,

so I got null when it read from ELF


On Tue, Feb 8, 2011 at 5:13 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 02/07/2011 07:22 AM, naveen yadav wrote:
>>
>> Thanks a lot for your input.
>>
>> This is o/p for my busybox.I am booting with INITRAMFS. and kernel
>> version is 2.6.30.9.
>> I also try latest codesourcery mips toolchain and result is same. I
>> could not get any hint to debug this issue.
>>
>
> The Debian mips/mipsel root filesystems will work with 64K pages.
>
> Install Debian, then use a chroot environment to debug your root filesystem.
> ?You should even be able to do that from within qemu.
>
>
>
>
>>
>> #mips-linux-gnu-readelf -l busybox
>>
>> Elf file type is EXEC (Executable file)
>> Entry point 0x400180
>> There are 5 program headers, starting at offset 52
>>
>> Program Headers:
>> ? Type ? ? ? ? ? Offset ? VirtAddr ? PhysAddr ? FileSiz MemSiz ?Flg Align
>> ? REGINFO ? ? ? ?0x0000f4 0x004000f4 0x004000f4 0x00018 0x00018 R ? 0x4
>> ? LOAD ? ? ? ? ? 0x000000 0x00400000 0x00400000 0x1a8c6f 0x1a8c6f R E
>> 0x10000
>> ? LOAD ? ? ? ? ? 0x1a9000 0x005b9000 0x005b9000 0x03170 0x084ac RW
>> ?0x10000
>> ? NOTE ? ? ? ? ? 0x0000d4 0x004000d4 0x004000d4 0x00020 0x00020 R ? 0x4
>> ? TLS ? ? ? ? ? ?0x1ab464 0x005bb464 0x005bb464 0x00018 0x0004c R ? 0x4
>>
>
> Why are you statically linking glibc? ?That is usually never a good idea.
>
> Other than that it looks reasonably sane.
>
>
>> ?Section to Segment mapping:
>> ? Segment Sections...
>> ? ?00 ? ? .reginfo
>> ? ?01 ? ? .note.ABI-tag .reginfo .rel.dyn .init .text
>> __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata
>> __libc_subfreeres __libc_atexit __libc_thread_subfreeres
>> .gcc_except_table
>> ? ?02 ? ? .eh_frame .tdata .ctors .dtors .jcr .data.rel.ro .data .got
>> .sdata .sbss .bss __libc_freeres_ptrs
>> ? ?03 ? ? .note.ABI-tag
>> ? ?04 ? ? .tdata .tbss
>>
>>
>> On Fri, Feb 4, 2011 at 11:09 PM, David Daney<ddaney@caviumnetworks.com>
>> ?wrote:
>>>
>>> On 02/04/2011 08:26 AM, Ian Lance Taylor wrote:
>>>>
>>>> keshav yadav<keshav.yadav2005@gmail.com> ? ?writes:
>>>>
>>>>> I observe one different behavior when we have page size set to 4KB or
>>>>> 16KB in kernel busybox receive argc[0] argument correct, but
>>>>> when page size set to 64KB I am getting argv[0] as empty. So what may
>>>>> be issue. I am using codesourcercy toolchain.
>>>>
>>>> I have no idea what the problem but I know that it is extremely unlikely
>>>> to have anything to do with gcc.
>>>>
>>>
>>> I agree.
>>>
>>> We routinely run programs compiled with a wide variety of stock GCC
>>> versions, under all three MIPS/Linux ABIs (o32, n32, n64) on kernels with
>>> 4K, 8K, 16K, 32K and 64K page sizes with no problems.
>>>
>>> If you suspect a defect in your toolchain, you could try building a
>>> 'stock'
>>> toolchain with recent Binutils and GCC versions.
>>>
>>> David Daney
>>>
>>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]