[ECOS] linux .rel.got problem

[ECOS] linux .rel.got problem

[Andrew Lunn]

Hi folks

I've run into one of the known problems with the synthetic linux
system. The problem is with the .rel.got section, problem #18956. 

The workaround is "Add a .rel.got linker-defined memory section to the
memory layout when building eCos under these conditions". Could
someone turn this in plainer English, ive no idea what to do! Im
behind a firewall so cannot get at the CVS repositry. 

Also, when new problems and workarounds and found, would it be
possible to send a message to ecos-discuss? Thats probably a better
way to keep up to date with what is going on, and the archives of the
emails are much easier to get at from behind a firewall.

	Thanks
		Andrew

Re: [ECOS] linux .rel.got problem

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <lunn@ma.tech.ascom.ch> writes:

Andrew> Hi folks I've run into one of the known problems with the
Andrew> synthetic linux system. The problem is with the .rel.got
Andrew> section, problem #18956.

Andrew> The workaround is "Add a .rel.got linker-defined memory
Andrew> section to the memory layout when building eCos under these
Andrew> conditions". Could someone turn this in plainer English, ive
Andrew> no idea what to do! Im behind a firewall so cannot get at the
Andrew> CVS repositry.

It's quite plain... but it may not be proper English :)

Below's the patch used to fix the PR:

Jesper


# cvs -q diff -D"05/14/1999 11:49:21 UTC" -D"05/14/1999 11:51:21 UTC" -u
Index: ChangeLog
===================================================================
RCS file: /cvs/ecc/ecc/hal/i386/arch/current/ChangeLog,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- ChangeLog	1999/05/13 18:00:33	1.34
+++ ChangeLog	1999/05/14 11:50:21	1.35
@@ -1,3 +1,7 @@
+1999-05-14  Jesper Skov  <jskov@cygnus.co.uk>
+        PR 18956
+	* src/i386.ld: Fixed problem with rel_got.
+
 1999-05-13  Hugo Tyson  <hmt@cygnus.co.uk>
 
 	* include/hal_arch.h (HAL_THREAD_INIT_CONTEXT): Align stack
Index: src/i386.ld
===================================================================
RCS file: /cvs/ecc/ecc/hal/i386/arch/current/src/i386.ld,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- src/i386.ld	1999/04/08 14:04:33	1.12
+++ src/i386.ld	1999/05/14 11:50:22	1.13
@@ -90,10 +90,9 @@
       _EXCEPT_END_ = ABSOLUTE(.);}                                      \
     > _region_
 
-#define SECTION_rel__got(_region_, _vma_, _lma_)        \
+#define SECTION_rel_got(_region_, _vma_, _lma_)        \
     .rel.got _vma_ : _lma_                                            \
-    { FORCE_OUTPUT;                           \
-      *(.rel.got)      }                                        \
+    { *(.rel.got)      }                                        \
     > _region_
 
 #define SECTION_data(_region_, _vma_, _lma_)                       \

# cvs -q diff -D"05/14/1999 11:49:24 UTC" -D"05/14/1999 11:51:24 UTC" -u
Index: ChangeLog
===================================================================
RCS file: /cvs/ecc/ecc/hal/i386/linux/current/ChangeLog,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ChangeLog	1999/04/08 14:04:34	1.24
+++ ChangeLog	1999/05/14 11:50:24	1.25
@@ -1,3 +1,9 @@
+1999-05-14  Jesper Skov  <jskov@cygnus.co.uk>
+        PR 18956
+	* include/pkgconf/mlt_i386_linux_ram.mlt: 
+	* include/pkgconf/mlt_i386_linux_ram.ldi: 
+	Fixed problem with rel_got.
+
 1999-04-08  John Dallaway  <jld@cygnus.co.uk>
 
 	* include/pkgconf/mlt_*.*: Use double underscore substitution
Index: include/pkgconf/mlt_i386_linux_ram.ldi
===================================================================
RCS file: /cvs/ecc/ecc/hal/i386/linux/current/include/pkgconf/mlt_i386_linux_ram.ldi,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- include/pkgconf/mlt_i386_linux_ram.ldi	1999/04/08 14:04:35	1.5
+++ include/pkgconf/mlt_i386_linux_ram.ldi	1999/05/14 11:50:25	1.6
@@ -31,11 +31,6 @@
     ram : ORIGIN = 0x00000000, LENGTH = 0x800000
 }
 
-// The rel__got section doesn't result in any output but the linker
-// complains if it is not present. It is necessary when compiling
-// with CYGIMP_LIBC_MALLOC_CXX_DELETE_CALLS_FREE=true but causes
-// problems with BFD when this option is false.
-
 SECTIONS
 {
     SECTIONS_BEGIN
@@ -46,7 +41,7 @@
     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_rel_got (ram, ALIGN (0x1), LMA_EQ_VMA)
     SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_sbss (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_bss (ram, ALIGN (0x10), LMA_EQ_VMA)
Index: include/pkgconf/mlt_i386_linux_ram.mlt
===================================================================
RCS file: /cvs/ecc/ecc/hal/i386/linux/current/include/pkgconf/mlt_i386_linux_ram.mlt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- include/pkgconf/mlt_i386_linux_ram.mlt	1999/03/04 09:48:58	1.1
+++ include/pkgconf/mlt_i386_linux_ram.mlt	1999/05/14 11:50:26	1.2
@@ -6,7 +6,8 @@
 section rodata1 0 8 0 1 0 1 0 1 rodata rodata !
 section rodata 0 8 0 1 0 1 0 1 fixup fixup !
 section fixup 0 4 0 1 0 1 0 1 gcc_except_table gcc_except_table !
-section gcc_except_table 0 1 0 1 0 1 0 1 data data !
+section gcc_except_table 0 1 0 1 0 1 0 1 rel_got rel_got !
+section rel_got 0 1 0 1 0 1 0 1 data data !
 section data 0 8 0 1 0 1 0 1 sbss sbss !
 section sbss 0 4 0 1 0 1 0 1 bss bss !
 section bss 0 10 0 1 0 0 0 0 !

Re: [ECOS] linux .rel.got problem

[Jesper Skov]

>>>>> "Jesper" == Jesper Skov <jskov@cygnus.co.uk> writes:
Jesper> Below's the patch used to fix the PR:

Which in turn introduces a problem for the ConfigTool. 

If you use the ConfigTool, you need to change the name of "rel_got"
section (in all the files) to "rel__got". 

The extra underbar is used to encode the '.' of the original section
name ("rel.got").

Sorry about that.

Jesper

Re: [ECOS] linux .rel.got problem

[Jamie Guinan]

On Mon, 21 Jun 1999, Andrew Lunn wrote:

> Hi folks
> 
> I've run into one of the known problems with the synthetic linux
> system. The problem is with the .rel.got section, problem #18956. 

Hello,

I've also bumped into this one.  It appeared at link time
when I introduced an "fopen()" call to my sources.

Before I apply the patch from CVS (thanks Jesper), is fopen()/fgets()
implemented for normal files under the Linux synthetic target?

If not, would a simple "linux filesystem driver" be worth spending
some time on?

Thanks,
-Jamie

Re: [ECOS] linux .rel.got problem

[Jonathan Larmour]

In article < Pine.LNX.3.96.990628160234.16277A-100000@newt.home.net >,
Jamie Guinan  <guinan@bluebutton.com> wrote:
>
>Before I apply the patch from CVS (thanks Jesper), is fopen()/fgets()
>implemented for normal files under the Linux synthetic target?

Fraid not.

>If not, would a simple "linux filesystem driver" be worth spending
>some time on?

We do have plans for an all-singing all-dancing configurable pluggable
virtual file system infrastructure :-), but it'll take some time to sort
out. Expect an RFC in the not-too-distant future. But if you want to hack
something quick and dirty up, feel free!

If you surround it by ifdefs for now, that'll make it nice and easy to find.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] linux .rel.got problem

[Jamie Guinan]

On 21 Jun 1999, Jesper Skov wrote:

> >>>>> "Jesper" == Jesper Skov <jskov@cygnus.co.uk> writes:
> Jesper> Below's the patch used to fix the PR:
> 
> Which in turn introduces a problem for the ConfigTool. 
> 
> If you use the ConfigTool, you need to change the name of "rel_got"
> section (in all the files) to "rel__got". 

Does that apply to running pkgconf.tcl manually as well? (Linux host).

And a more general question: after applying your patches,
is it then necessary to run pkgconf.tcl to generate a new
<build>/install/lib/target.ld ?

Thanks,
-Jamie

Re: [ECOS] linux .rel.got problem

[Jesper Skov]

>>>>> "Jamie" == Jamie Guinan <guinan@bluebutton.com> writes:

Jamie> On 21 Jun 1999, Jesper Skov wrote:
>> >>>>> "Jesper" == Jesper Skov <jskov@cygnus.co.uk> writes:
Jesper> Below's the patch used to fix the PR:
>>  Which in turn introduces a problem for the ConfigTool.
>> 
>> If you use the ConfigTool, you need to change the name of "rel_got"
>> section (in all the files) to "rel__got".

Jamie> Does that apply to running pkgconf.tcl manually as well? (Linux
Jamie> host).

No. As long as the naming is consistent it should be OK on Linux.

Jamie> And a more general question: after applying your patches, is it
Jamie> then necessary to run pkgconf.tcl to generate a new
Jamie> <build>/install/lib/target.ld ?

There's a dependency on the i386/arch script so it should be picked up
automatically. But you need to either rerun pkgconf or copy the new
mlt_i386_linux_ram.ldi to your build tree by hand.

Jesper

[ECOS] Linux Filesystem Access

[Jamie Guinan]

On 28 Jun 1999, Jonathan Larmour wrote:

> Jamie Guinan  <guinan@bluebutton.com> wrote:
> 
> >If not, would a simple "linux filesystem driver" be worth spending
> >some time on?
> 
> We do have plans for an all-singing all-dancing configurable pluggable
> virtual file system infrastructure :-), but it'll take some time to sort
> out. Expect an RFC in the not-too-distant future.

Looking forward to that!  So right now the only things I can fopen()
are /dev entries like "/dev/haldiag", correct?

> But if you want to hack
> something quick and dirty up, feel free!

Actually, I found that the stuff from syscall-i386-linux-1.0.S
works well enough for me.  I am able to open and write files
with code such as,

  #define O_WRONLY             01
  #define O_CREAT            0100

  int fd;
  char *buff = "Boogie down!\n";
  fd=cyg_hal_sys_open("/tmp/ecos.out", O_CREAT|O_WRONLY, 00777);
  cyg_hal_sys_write(fd, buff, strlen(buff));
  cyg_hal_sys_close(fd);

I have yet to try reading, though.

-Jamie

[ECOS] Re: Linux Filesystem Access

[Jamie Guinan]

On Wed, 30 Jun 1999, Jamie Guinan wrote:

> Actually, I found that the stuff from syscall-i386-linux-1.0.S
> works well enough for me.  I am able to open and write files
> with code such as,
...
> I have yet to try reading, though.

Hm, cyg_sys_hal_read() seems to block eCos entirely.  Guess
I have some more thinking to do.

What I would like to do is block on a read() from some external
source under eCos/synthetic-linux.  This way I can test code
that will eventually read from a serial port on my embedded
PowerPC target.

-Jamie