[ECOS] Position Independent Code

[ECOS] Position Independent Code

[Slide]

All,

Does eCos work if I build for PIC? I would like to be able to move my
application around in memory as much as possible.

Thanks,

slide

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

Re: [ECOS] Position Independent Code

[Andrew Lunn]

On Tue, Oct 09, 2007 at 10:13:16AM -0700, Slide wrote:
> All,
> 
> Does eCos work if I build for PIC? 

No.

        Andrew

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

Re: [ECOS] Position Independent Code

[Gary Thomas]

Slide wrote:
> All,
> 
> Does eCos work if I build for PIC? I would like to be able to move my
> application around in memory as much as possible.

In general, PIC code suffers both size and performance penalties.
eCos is all about the most configurable (and hopefully most
optimal) solution, so we've never supported PIC.

Why would you want to do this?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Re: [ECOS] Position Independent Code

[Gary Thomas]

Slide wrote:
> On 10/9/07, Gary Thomas <gary@mlbassoc.com> wrote:
>> Slide wrote:
>>> All,
>>>
>>> Does eCos work if I build for PIC? I would like to be able to move my
>>> application around in memory as much as possible.
>> In general, PIC code suffers both size and performance penalties.
>> eCos is all about the most configurable (and hopefully most
>> optimal) solution, so we've never supported PIC.
>>
>> Why would you want to do this?
>>
> 
> 
> Perhaps I am just thinking about this the wrong way then. What I would
> like is an application image that I can load to any address I want. My
> bootloader will handle setting up virtual memory, so I guess all I
> really have to do is compile for a constant virtual address which will
> be mapped by my bootloader to any of the memory regions I am
> interested in. Does this sound like a better solution?

Yes, this is the basic approach taken by eCos, although in general
there's no "virtual" memory mapping involved.

BTW, please keep your replies on the list so that all may
benefit.  Private email [with MLB Associates] is available
only with a support contract.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Re: [ECOS] Position Independent Code

[Slide]

On 10/9/07, Gary Thomas <gary@mlbassoc.com> wrote:
> Slide wrote:
> > On 10/9/07, Gary Thomas <gary@mlbassoc.com> wrote:
> >> Slide wrote:
> >>> All,
> >>>
> >>> Does eCos work if I build for PIC? I would like to be able to move my
> >>> application around in memory as much as possible.
> >> In general, PIC code suffers both size and performance penalties.
> >> eCos is all about the most configurable (and hopefully most
> >> optimal) solution, so we've never supported PIC.
> >>
> >> Why would you want to do this?
> >>
> >
> >
> > Perhaps I am just thinking about this the wrong way then. What I would
> > like is an application image that I can load to any address I want. My
> > bootloader will handle setting up virtual memory, so I guess all I
> > really have to do is compile for a constant virtual address which will
> > be mapped by my bootloader to any of the memory regions I am
> > interested in. Does this sound like a better solution?
>
> Yes, this is the basic approach taken by eCos, although in general
> there's no "virtual" memory mapping involved.
>
> BTW, please keep your replies on the list so that all may
> benefit.  Private email [with MLB Associates] is available
> only with a support contract.
>
> --


Sorry, gmail tends to do that to me. Thanks for the information.

slide

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

[ECOS] error: no memory region specified for loadable section `.got'

[Scott Moore]

Hi, 

we are trying to compile ecos with a later version than the default
supplied arm toolset. Ecos compiles to a .a just fine, but then the
final compile/link (in this case the example "hello.c") fails with
the error:

===============================================================================
C:\projects\ecos_examples>arm-unknown-linux-gnu-gcc -nostartfiles -Lc:/projects/
ecos_test/install/lib -Ttarget.ld -static -mcpu=arm7tdmi -Wl,--gc-sections -Wl,-
static -g -nostdlib -o hello.elf hello.o
/home/samiam/opt/crosstool/gcc-4.1.0-glibc-2.3.2/arm-unknown-linux-gnu/lib/gcc/a
rm-unknown-linux-gnu/4.1.0/../../../../arm-unknown-linux-gnu/bin/ld: error: no m
emory region specified for loadable section `.got'
collect2: ld returned 1 exit status

C:\projects\ecos_examples>
===============================================================================

As you can see, we are trying the gcc 4.1.0 compiler.

So far, all we have seen is that .got implies "position independent code" mode.
I didn't see an option to turn this mode off, we don't need or want it.

Thank you.

Scott Moore
Powerfile Inc.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


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

[ECOS] Problem with obtaining sockaddr from recvfrom()

[jerzy dyrda]

Hello all,

I have problem with obtaining sockaddr from recvfrom() - function doesn't 
return any socket address.

I do it in such way :

Socket is opened for UDP datagram :
 fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

and bind to some port:

addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(RMCP_UDP_PORT);
rc = bind (fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in));

and next I'm waiting for a packet:
ret = recvfrom(fd, &rmcp_packet_raw, IPMI_BUF_SIZE, 0,
					&remote_addr, &remote_addr_len);
Received packet is correct according to length and contents but as I mention 
in subject without a socket addres. It's confusing for me because the same 
code works as Linux application. 

I'm using FreeBsd stack from version 2_0 of eCos

Any suggestion is appreciated.

Best regards,
jerzy

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

Re: [ECOS] Problem with obtaining sockaddr from recvfrom()

[Richard Pennington]

jerzy dyrda wrote:
> Hello all,
> 
> I have problem with obtaining sockaddr from recvfrom() - function doesn't 
> return any socket address.
> 
> I do it in such way :
> 
> Socket is opened for UDP datagram :
>  fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
> 
> and bind to some port:
> 
> addr.sin_family = AF_INET;
> addr.sin_addr.s_addr = htonl(INADDR_ANY);
> addr.sin_port = htons(RMCP_UDP_PORT);
> rc = bind (fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in));
> 
> and next I'm waiting for a packet:
> ret = recvfrom(fd, &rmcp_packet_raw, IPMI_BUF_SIZE, 0,
> 					&remote_addr, &remote_addr_len);
> Received packet is correct according to length and contents but as I mention 
> in subject without a socket addres. It's confusing for me because the same 
> code works as Linux application. 
> 
> I'm using FreeBsd stack from version 2_0 of eCos
> 
> Any suggestion is appreciated.
> 
> Best regards,
> jerzy
> 
Not sure if this is your problem, but I have
#if defined(__ECOS)
     addr.sin_len = sizeof(addr);
#endif

in code that I use.

-Rich

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

Re: [ECOS] Problem with obtaining sockaddr from recvfrom()

[Gary Thomas]

Richard Pennington wrote:
> jerzy dyrda wrote:
>> Hello all,
>>
>> I have problem with obtaining sockaddr from recvfrom() - function
>> doesn't return any socket address.
>>
>> I do it in such way :
>>
>> Socket is opened for UDP datagram :
>>  fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
>>
>> and bind to some port:
>>
>> addr.sin_family = AF_INET;
>> addr.sin_addr.s_addr = htonl(INADDR_ANY);
>> addr.sin_port = htons(RMCP_UDP_PORT);
>> rc = bind (fd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in));
>>
>> and next I'm waiting for a packet:
>> ret = recvfrom(fd, &rmcp_packet_raw, IPMI_BUF_SIZE, 0,
>>                     &remote_addr, &remote_addr_len);
>> Received packet is correct according to length and contents but as I
>> mention in subject without a socket addres. It's confusing for me
>> because the same code works as Linux application.
>> I'm using FreeBsd stack from version 2_0 of eCos
>>
>> Any suggestion is appreciated.
>>
>> Best regards,
>> jerzy
>>
> Not sure if this is your problem, but I have
> #if defined(__ECOS)
>     addr.sin_len = sizeof(addr);
> #endif
> 
> in code that I use.

This is quite possibly the source of the problem.

The standard test program:
  .../net/common/current/tests/udp_lo_test.c
does a recvfrom() and successfully prints the source address,
so we're pretty sure that the system [calls] work properly.

Try looking at the test/example programs.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Re: [ECOS] Problem with obtaining sockaddr from recvfrom()

[jerzy dyrda]

Hello all,

> > Not sure if this is your problem, but I have
> > #if defined(__ECOS)
> >     addr.sin_len = sizeof(addr);
> > #endif
> >
> > in code that I use.
>
> This is quite possibly the source of the problem.
>
> The standard test program:
>   .../net/common/current/tests/udp_lo_test.c
> does a recvfrom() and successfully prints the source address,
> so we're pretty sure that the system [calls] work properly.
>
> Try looking at the test/example programs.
Thanks a lot for hints and suggestions.
The case was missing of initialization addr_len with length of structure  
before calling recvfrom() i.e.
/* remote_addr_len == 0 */
ret = recvfrom(fd, &rmcp_packet_raw, IPMI_BUF_SIZE, 0,
                                       &remote_addr, &remote_addr_len);
and as I suppose recvfrom() treat remote_addr as structure with zero length 
buffer :(
 
It's done in the standard test program udp_lo_test.c

    c_len = sizeof(c_addr);
   ^^^^^^^^^^^^^^
	
    if ((len = recvfrom(s_source, data_buf, sizeof(data_buf),0,
                        (struct sockaddr *)&c_addr,&c_len)) < 0  ) {
        CYG_TEST_FAIL_FINISH("I/O error");
    }


Best regards,
jerzy

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

RE: [ECOS] error: no memory region specified for loadable section `.got'

[Chris Zimman]

> we are trying to compile ecos with a later version than the default
> supplied arm toolset. Ecos compiles to a .a just fine, but then the
> final compile/link (in this case the example "hello.c") fails with
> the error:
> 
>
=============================================================================
==
> C:\projects\ecos_examples>arm-unknown-linux-gnu-gcc -nostartfiles
-Lc:/projects/
> ecos_test/install/lib -Ttarget.ld -static -mcpu=arm7tdmi -Wl,--gc-sections
-Wl,-
> static -g -nostdlib -o hello.elf hello.o
>
/home/samiam/opt/crosstool/gcc-4.1.0-glibc-2.3.2/arm-unknown-linux-gnu/lib/gc
c/a
> rm-unknown-linux-gnu/4.1.0/../../../../arm-unknown-linux-gnu/bin/ld: error:
no m
> emory region specified for loadable section `.got'
> collect2: ld returned 1 exit status
>
> C:\projects\ecos_examples>
>
=============================================================================
==
>
> As you can see, we are trying the gcc 4.1.0 compiler.
> 
> So far, all we have seen is that .got implies "position independent code"
mode.
> I didn't see an option to turn this mode off, we don't need or want it.

Hi Scott,

There are a couple of problems here as far as I can see.  First, you should
be using arm-elf-gcc, not arm-linux-gcc.  Second, I have had mixed experience
trying to use GCC 4.x with eCos.  We had problems with it -- basically code
would sometimes crash for no apparent reason that would work fine under
3.4.4.  I didn't have any particularly compelling reason to move to 4.x so
we've elected to stay with 3.4.4 for the time being.

--Chris

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