[ECOS] rodata feature :-(

[ECOS] rodata feature :-(

[Boris V. Guzhov]

Hi All,

There is a very interesting  feature of the "rodata" section.

There is the a.out program that linked with the following linker
script (mlt_i386_pc_ram.ldi):
MEMORY
{
    ram : ORIGIN = 0x0, LENGTH = 0x800000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_vectors (ram, 0x10000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_rel__got (ram, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_data (ram, 0x100000, LMA_EQ_VMA)
    SECTION_sbss (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x10), LMA_EQ_VMA)
    SECTIONS_END
}

It's "nm -gn a.out" output:
....
0007a0e0 R bit_first_set8
00092d08 R  Cyg_libc_str_null_mask_1
 00092d10 R Cyg_libc_str_null_mask_2
0009522f R nothrow
00095360 A _EXCEPT_END_
....
There is strange memory hole between "bit_first_set8" and "
Cyg_libc_str_null_mask_1":
0x92d08 - 0x7a0e0 = 0x18C28 (~100 kb).

How can you explain it?

Note that:
- the bit_first_set8 declaration is  "extern const unsigned char
bit_first_set8[256];",
- the bit_first_set8 and Cyg_libc_str_null_mask_*  variables are declared in
different files.

Thanks in advance.

--
Boris Guzhov,
St.Petersburg, Russia

Re: [ECOS] rodata feature :-(

[Jonathan Larmour]

"Boris V. Guzhov" wrote:
> There is strange memory hole between "bit_first_set8" and "
> Cyg_libc_str_null_mask_1":
> 0x92d08 - 0x7a0e0 = 0x18C28 (~100 kb).
> 
> How can you explain it?
> 
> Note that:
> - the bit_first_set8 declaration is  "extern const unsigned char
> bit_first_set8[256];",
> - the bit_first_set8 and Cyg_libc_str_null_mask_*  variables are declared in
> different files.

Seems like some sort of tools problem. Have you tried generating a linker
map? Perhaps do an objdump --section-headers on the relevant intermediate
object files (i.e. .o files) to see if any of them have odd alignment
constraints or sizes. If so, try examining the assembly version of the
affected files to see how it is coming about.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] rodata feature :-(

[Boris V. Guzhov]

> > There is strange memory hole between "bit_first_set8" and "
> > Cyg_libc_str_null_mask_1":
> > 0x92d08 - 0x7a0e0 = 0x18C28 (~100 kb).
> >
> > How can you explain it?
> >
> > Note that:
> > - the bit_first_set8 declaration is  "extern const unsigned char
> > bit_first_set8[256];",
> > - the bit_first_set8 and Cyg_libc_str_null_mask_*  variables are
declared in
> > different files.
>
> Seems like some sort of tools problem. Have you tried generating a linker
> map? Perhaps do an objdump --section-headers on the relevant intermediate
> object files (i.e. .o files) to see if any of them have odd alignment
> constraints or sizes. If so, try examining the assembly version of the
> affected files to see how it is coming about.
>
> Jifl


Thanks,

I used objdump and objcopy and realized that is due to ASSERT .
I my eCos configuration are used ASSERTs (CYGPKG_INFRA_DEBUG=1,
CYGDBG_USE_ASSERTS=1). These options provide too
many of constant strings in project and "nm" command does not
show them.

--
Boris Guzhov,
St.Petersburg, Russia