[ECOS] Some Question about the Linker script in ecos.

[ECOS] Some Question about the Linker script in ecos.

[Qiang Huang]

Hi:
   I am trying to figure out how the linker script works in ecos. I have
some question about the linker scipt in ecos.
take ARM E7T as example. There is a linker script in
hal\arm\arch\src\arm.ld,  in
\hal\arm\e7t\current\include\pkgconf\mlt_arm_e7t_ram.ldi and
mlt_arm_e7t_ram.mlt, so what is different between those two files in the
\e7t\ directory with the one called arm.ld in \hal\arm\arch? If I build the
app using ARM E7T default template which linker script will be used during
the process building the ecos library? also which will be used while I try
to link my app with the built ecos library? Thanks for your help.

Best regards

james


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Some Question about the Linker script in ecos.

[Gary Thomas]

On Fri, 2002-06-28 at 04:29, Qiang Huang wrote:
> Hi:
>    I am trying to figure out how the linker script works in ecos. I have
> some question about the linker scipt in ecos.
> take ARM E7T as example. There is a linker script in
> hal\arm\arch\src\arm.ld,  in
> \hal\arm\e7t\current\include\pkgconf\mlt_arm_e7t_ram.ldi and
> mlt_arm_e7t_ram.mlt, so what is different between those two files in the
> \e7t\ directory with the one called arm.ld in \hal\arm\arch? If I build the
> app using ARM E7T default template which linker script will be used during
> the process building the ecos library? also which will be used while I try
> to link my app with the built ecos library? Thanks for your help.

The appropriate "mlt*ldi" and the architecture file "arm.ld" are 
combined to create "target.ld", which is what actually gets passed to
the linker.  Think of it like this: "arm.ld" is the template and the
"mlt*ldi" file are the specifics for how to instantiate that template
to create the actual linker file which in turn describes how the program
will be laid out in memory.

The "mlt*.mlt" files are an internal representation of the "mlt*.ldi"
files, used by the "Memory Layout Tool"


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] problem with memory allocation on SNDS-100 board

[benny]

Looks like there is a bug in mlt_arm_snds_ram.ldi:
section 	CYG_LABEL_DEFN(__heap1) = ALIGN (0x8) is missing.
Therefore malloc() left with just 16k of fall-back memory.
I changed the file manually but heaps.hxx was not regenerated.
I tried to modify heaps.hxx manually, then I got another conflict...
What should be the correct way to change the layout and add heap - 
it appears to me that config tool doesn't trace .ldi changes...
I saw some tcl tool but what should be procedure to use it?

Regards,
Benny


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] problem with memory allocation on SNDS-100 board

[Grant Edwards]

On Tue, Jul 02, 2002 at 05:55:41PM -0600, benny wrote:

> Looks like there is a bug in mlt_arm_snds_ram.ldi:
> section 	CYG_LABEL_DEFN(__heap1) = ALIGN (0x8) is missing.
> Therefore malloc() left with just 16k of fall-back memory.

Yup.  I'm not sure where I got the original .ldi from from
which that was copied, but another HAL for a similar platform
had the same problem.

> I changed the file manually but heaps.hxx was not regenerated.

You'll have to re-generate the source tree from scratch.

> I tried to modify heaps.hxx manually, then I got another conflict...
> What should be the correct way to change the layout and add heap - 
> it appears to me that config tool doesn't trace .ldi changes...
> I saw some tcl tool but what should be procedure to use it?

$ ecosconfig new snds ...

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] problem with memory allocation on SNDS-100 board

[Grant Edwards]

On Tue, 2002-07-02 at 17:22, Grant Edwards wrote:
> On Tue, Jul 02, 2002 at 05:55:41PM -0600, benny wrote:
> 
> > Looks like there is a bug in mlt_arm_snds_ram.ldi:
> > section 	CYG_LABEL_DEFN(__heap1) = ALIGN (0x8) is missing.
> > Therefore malloc() left with just 16k of fall-back memory.
> 
> Yup.  I'm not sure where I got the original .ldi from from
> which that was copied, but another HAL for a similar platform
> had the same problem.
> 
> > I changed the file manually but heaps.hxx was not regenerated.
> 
> You'll have to re-generate the source tree from scratch.
> 
> > I tried to modify heaps.hxx manually, then I got another conflict...
> > What should be the correct way to change the layout and add heap - 
> > it appears to me that config tool doesn't trace .ldi changes...
> > I saw some tcl tool but what should be procedure to use it?
> 
> $ ecosconfig new snds ...

Now that I think about it, I don't think you have to start from
scratch.  Try deleting everything except ecos.ecc and then just
doing 

 $ ecosconfig tree
 
-- 
Grant Edwards
grante@visi.com



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] ARM7 problem with ldr assembly instruction

[benny]

I have c-code, where the register should get 32-bit value from the
memory, which happens to be not 32-bit aligned (16-bit aligned).
The C-line looks like:
ip_address.s_addr = ((UDP_CONNECT_T*)data_ptr)->ip_address;
and ip_address is not on 32-bit boundary.

My compiler 2.95.2 for ARM generates instruction:

ldr r1, [r11, -#102]

What a surprise - this instruction doesn't do anything !!!
the contents of r1 didn't change !!!

If the address is 32-bit aligned, then everything works fine.
There are no warnings neither from compiler, nor from the execution module
(like abort).

My question:
is this a ARM core bug, specific processor bug (I use Samsung C4510),
compiler
bug or my own bug.
If ldr doesn't allow not-aligned access, then how is it possible to avoid
such
conditions in the code?

It is not eCOS specific question (may be tool question) but may be somebody
here
know the answer?

Regards,
Benny


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM7 problem with ldr assembly instruction

[Gary Thomas]

On Fri, 2002-07-12 at 11:19, benny wrote:
> I have c-code, where the register should get 32-bit value from the
> memory, which happens to be not 32-bit aligned (16-bit aligned).
> The C-line looks like:
> ip_address.s_addr = ((UDP_CONNECT_T*)data_ptr)->ip_address;
> and ip_address is not on 32-bit boundary.
> 
> My compiler 2.95.2 for ARM generates instruction:
> 
> ldr r1, [r11, -#102]
> 
> What a surprise - this instruction doesn't do anything !!!
> the contents of r1 didn't change !!!
> 
> If the address is 32-bit aligned, then everything works fine.
> There are no warnings neither from compiler, nor from the execution module
> (like abort).
> 
> My question:
> is this a ARM core bug, specific processor bug (I use Samsung C4510),
> compiler
> bug or my own bug.
> If ldr doesn't allow not-aligned access, then how is it possible to avoid
> such
> conditions in the code?
> 

It depends on the ARM core, but most do not support unaligned
operations.

How to make sure things are aligned?
  * First, use the correct data size.  'long' and 'int' should be forced
    by the compiler to be 32 bit aligned.
  * Most alignment problems happen when you cast things to different 
    size operands.  If you need to do this, then use a function which
    operates on small pieces and reconstructs, rather than trying to 
    just "cast" your way out of it.  e.g. instead of
       *(int *)&a
    use
       (((short *)&a)[1] << 16) | (((short *)&a)[0] << 0)
    The one concern here is to make sure you preserve the endian-ness
    of the accesses.

> It is not eCOS specific question (may be tool question) but may be somebody
> here
> know the answer?
> 
> Regards,
> Benny
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] ARM7 problem with ldr assembly instruction

[benny]

Gary, thanks a lot!
I'll use your suggestions.
I know it is not your call but wouldn't be logical to assume at least core
exception in such case (abort) like Motorola had once rather then the
instruction
that doesn't do anything :-(
I'll try to ask ARM and will post the answer if it will be any :-)

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Friday, July 12, 2002 10:34 AM
> To: benny@voicepump.com
> Cc: Ecos-Discuss (E-mail)
> Subject: Re: [ECOS] ARM7 problem with ldr assembly instruction
>
>
> On Fri, 2002-07-12 at 11:19, benny wrote:
> > I have c-code, where the register should get 32-bit value from the
> > memory, which happens to be not 32-bit aligned (16-bit aligned).
> > The C-line looks like:
> > ip_address.s_addr = ((UDP_CONNECT_T*)data_ptr)->ip_address;
> > and ip_address is not on 32-bit boundary.
> >
> > My compiler 2.95.2 for ARM generates instruction:
> >
> > ldr r1, [r11, -#102]
> >
> > What a surprise - this instruction doesn't do anything !!!
> > the contents of r1 didn't change !!!
> >
> > If the address is 32-bit aligned, then everything works fine.
> > There are no warnings neither from compiler, nor from the
> execution module
> > (like abort).
> >
> > My question:
> > is this a ARM core bug, specific processor bug (I use Samsung C4510),
> > compiler
> > bug or my own bug.
> > If ldr doesn't allow not-aligned access, then how is it
> possible to avoid
> > such
> > conditions in the code?
> >
>
> It depends on the ARM core, but most do not support unaligned
> operations.
>
> How to make sure things are aligned?
>   * First, use the correct data size.  'long' and 'int' should be forced
>     by the compiler to be 32 bit aligned.
>   * Most alignment problems happen when you cast things to different
>     size operands.  If you need to do this, then use a function which
>     operates on small pieces and reconstructs, rather than trying to
>     just "cast" your way out of it.  e.g. instead of
>        *(int *)&a
>     use
>        (((short *)&a)[1] << 16) | (((short *)&a)[0] << 0)
>     The one concern here is to make sure you preserve the endian-ness
>     of the accesses.
>
> > It is not eCOS specific question (may be tool question) but may
> be somebody
> > here
> > know the answer?
> >
> > Regards,
> > Benny
> >
> >
> > --
> > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM7 problem with ldr assembly instruction

[Roland Caßebohm]

On Friday, 12. July 2002 19:37, benny wrote:
> Gary, thanks a lot!
> I'll use your suggestions.
> I know it is not your call but wouldn't be logical to assume at least core
> exception in such case (abort) like Motorola had once rather then the
> instruction
> that doesn't do anything :-(
> I'll try to ask ARM and will post the answer if it will be any :-)

I had the same problem but in my case the ARM made an exception. The solution 
is to add -mno-short-load-words to the compiler flags. I think in the AT91 
platform this is done but it is missing for the SNDS platform.

Regards,
Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] ARM7 problem with ldr assembly instruction

[Gary Thomas]

On Fri, 2002-07-12 at 11:37, benny wrote:
> Gary, thanks a lot!
> I'll use your suggestions.
> I know it is not your call but wouldn't be logical to assume at least core
> exception in such case (abort) like Motorola had once rather then the
> instruction
> that doesn't do anything :-(
> I'll try to ask ARM and will post the answer if it will be any :-)
> 

Again, different cores behave differently.  Some in fact do support
and exception on un-aligned accesses, but not all.  I have a feeling
that the simple 7TDMI core you're working with does not, but I don't
have the data in front of me to say for sure.

> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Friday, July 12, 2002 10:34 AM
> > To: benny@voicepump.com
> > Cc: Ecos-Discuss (E-mail)
> > Subject: Re: [ECOS] ARM7 problem with ldr assembly instruction
> >
> >
> > On Fri, 2002-07-12 at 11:19, benny wrote:
> > > I have c-code, where the register should get 32-bit value from the
> > > memory, which happens to be not 32-bit aligned (16-bit aligned).
> > > The C-line looks like:
> > > ip_address.s_addr = ((UDP_CONNECT_T*)data_ptr)->ip_address;
> > > and ip_address is not on 32-bit boundary.
> > >
> > > My compiler 2.95.2 for ARM generates instruction:
> > >
> > > ldr r1, [r11, -#102]
> > >
> > > What a surprise - this instruction doesn't do anything !!!
> > > the contents of r1 didn't change !!!
> > >
> > > If the address is 32-bit aligned, then everything works fine.
> > > There are no warnings neither from compiler, nor from the
> > execution module
> > > (like abort).
> > >
> > > My question:
> > > is this a ARM core bug, specific processor bug (I use Samsung C4510),
> > > compiler
> > > bug or my own bug.
> > > If ldr doesn't allow not-aligned access, then how is it
> > possible to avoid
> > > such
> > > conditions in the code?
> > >
> >
> > It depends on the ARM core, but most do not support unaligned
> > operations.
> >
> > How to make sure things are aligned?
> >   * First, use the correct data size.  'long' and 'int' should be forced
> >     by the compiler to be 32 bit aligned.
> >   * Most alignment problems happen when you cast things to different
> >     size operands.  If you need to do this, then use a function which
> >     operates on small pieces and reconstructs, rather than trying to
> >     just "cast" your way out of it.  e.g. instead of
> >        *(int *)&a
> >     use
> >        (((short *)&a)[1] << 16) | (((short *)&a)[0] << 0)
> >     The one concern here is to make sure you preserve the endian-ness
> >     of the accesses.
> >
> > > It is not eCOS specific question (may be tool question) but may
> > be somebody
> > > here
> > > know the answer?
> > >
> > > Regards,
> > > Benny
> > >
> > >
> > > --
> > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> >
> >
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM7 problem with ldr assembly instruction

[Grant Edwards]

On Fri, Jul 12, 2002 at 10:53:18AM -0600, Gary Thomas wrote:

> Again, different cores behave differently.  Some in fact do
> support and exception on un-aligned accesses, but not all.  I
> have a feeling that the simple 7TDMI core you're working with
> does not, but I don't have the data in front of me to say for
> sure.

I'm using the same part (Samsung '4510), and my recollection is
that unaligned accesses do not generate data aborts, they just
don't work.  IIRC, they're not always noops either -- they may
write something to the register or memory, but it may not be
what you wanted.

-- 
Grant Edwards
grante@visi.com

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] ARM7 problem with ldr assembly instruction

[Martin Buck]

benny wrote:
> I know it is not your call but wouldn't be logical to assume at least core
> exception in such case (abort) like Motorola had once rather then the
> instruction
> that doesn't do anything :-(

Did you actually install an exception handler using
cyg_exception_set_handler()? If not, eCos will use its default exception
handler which does nothing (in the default configuration, that is).

Martin

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss