* [ECOS] 64 bit mips arch, and __DEVTAB__
@ 2000-07-12 15:15 Chris Morrow
2000-07-12 15:24 ` Gary Thomas
0 siblings, 1 reply; 5+ messages in thread
From: Chris Morrow @ 2000-07-12 15:15 UTC (permalink / raw)
To: ecos-discuss
I'm working on porting eCos to a 64 bit mips cpu and have encountered
a problem with the DEVTAB_ENTRY macro defined in
io/common/current/include/devtab.h. It would appear that gcc is aligning
each piece of data added to the .devtab section on 8 byte boundries.
This
causes a space between entries and causes the loop in cyg_io_init() in
io/commmon/current/iosys.c to fail.
Depending on whether it is legitimate to assume that there is no padding
for data objects added separately to a section with the section
__attribute__,
this may be a compiler issue rather than a eCos issue.
A simple work around exists, by just adding another field to the
cyg_devtab_entry
structure.
Here is a simple example of the problem.
--- bug.h ---
typedef struct cyg_devtab_entry {
const char *name;
const char *dep_name;
void *handlers;
int (*init)();
int (*lookup)();
void *priv;
unsigned long status;
} cyg_devtab_entry_t;
extern cyg_devtab_entry_t __DEVTAB__[], __DEVTAB_END__;
#define DEVTAB_ENTRY(_l,_name,_dep_name,_handlers,_init,_lookup,_priv)
\
cyg_devtab_entry_t _l __attribute__ ((section(".devtab"))) = {
\
_name,
\
_dep_name,
\
_handlers,
\
_init,
\
_lookup,
\
_priv
\
};
--- bug.c ---
#include "bug.h"
int
f()
{
return 0;
}
DEVTAB_ENTRY(a, "a", "a", (void *)1, f, f, (void *)1);
DEVTAB_ENTRY(b, "b", "b", (void *)1, f, f, (void *)1);
void
_start()
{
cyg_devtab_entry_t *t;
for (t = &__DEVTAB__[0]; t != &__DEVTAB_END__; t++) {
if (t->init(t)) {
t->status = 1;
} else {
// What to do if device init fails?
t->status = 0; // Device not [currently] available
}
}
}
--- target.ld ---
SECTIONS
{
. = 0x10000;
.text ALIGN(0x4) : { *(.text) }
. = 0x8000000;
.data ALIGN(0x8) : {
*(.data);
. = ALIGN (8);
__DEVTAB__ = ABSOLUTE(.);
KEEP (*(SORT (.devtab*)))
__DEVTAB_END__ = ABSOLUTE(.);
}
.bss ALIGN(0x8) : { *(.bss) }
}
--- Makefile ---
CC = mips64-unknown-elf-gcc
CFLAGS = -v \
-ffunction-sections \
-fdata-sections \
-Ttarget.ld \
-nostartfiles
bug: bug.o bug.h
$(CC) -c $(CFLAGS) bug.c
$(CC) $(CFLAGS) bug.o -o $@
--- Make output ---
mips64-unknown-elf-gcc -v -ffunction-sections -fdata-sections
-Ttarget.ld -nostartfiles -c bug.c -o bug.o
Reading specs from
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/cpp -lang-c
-v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dmips -DMIPSEB -DR4000 -D_mips
-D_MIPSEB -D_R4000 -D__mips__ -D__MIPSEB__ -D__R4000__ -D___mips__
-D_MIPSEB -D_R4000 -D__mips -D__MIPSEB -D__R4000 -D___mips
-D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=unsigned int
-D__PTRDIFF_TYPE__=int -U__mips -D__mips=3 -D__mips64 bug.c
/tmp/ccCyvoQ1.i
GNU CPP version 2.95.2 19991024 (release) [AL 1.1, MM 40] BSD Mips
#include "..." search starts here:
#include <...> search starts here:
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/include
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../mips64-unknown-elf/include
End of search list.
The following default directories have been omitted from the search
path:
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../include/g++-3
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../mips64-unknown-elf/sys-include
End of omitted list.
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/cc1
/tmp/ccCyvoQ1.i -quiet -dumpbase bug.c -version -ffunction-sections
-fdata-sections -o /tmp/cciIREaT.s
GNU C version 2.95.2 19991024 (release) (mips64-unknown-elf) compiled by
GNU C version 2.95.2 19991024 (release).
/home/yotta/software/mips64-unknown-elf/bin/as -v -o bug.o
/tmp/cciIREaT.s
GNU assembler version 2.10 (mips64-unknown-elf) using BFD version 2.10
mips64-unknown-elf-gcc -c -v -ffunction-sections -fdata-sections
-Ttarget.ld -nostartfiles bug.c
Reading specs from
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/cpp -lang-c
-v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dmips -DMIPSEB -DR4000 -D_mips
-D_MIPSEB -D_R4000 -D__mips__ -D__MIPSEB__ -D__R4000__ -D___mips__
-D_MIPSEB -D_R4000 -D__mips -D__MIPSEB -D__R4000 -D___mips
-D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=unsigned int
-D__PTRDIFF_TYPE__=int -U__mips -D__mips=3 -D__mips64 bug.c
/tmp/cciE8dn5.i
GNU CPP version 2.95.2 19991024 (release) [AL 1.1, MM 40] BSD Mips
#include "..." search starts here:
#include <...> search starts here:
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/include
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../mips64-unknown-elf/include
End of search list.
The following default directories have been omitted from the search
path:
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../include/g++-3
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/../../../../mips64-unknown-elf/sys-include
End of omitted list.
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/cc1
/tmp/cciE8dn5.i -quiet -dumpbase bug.c -version -ffunction-sections
-fdata-sections -o /tmp/cc0I4j8Z.s
GNU C version 2.95.2 19991024 (release) (mips64-unknown-elf) compiled by
GNU C version 2.95.2 19991024 (release).
/home/yotta/software/mips64-unknown-elf/bin/as -v -o bug.o
/tmp/cc0I4j8Z.s
GNU assembler version 2.10 (mips64-unknown-elf) using BFD version 2.10
mips64-unknown-elf-gcc -v -ffunction-sections -fdata-sections
-Ttarget.ld -nostartfiles bug.o -o bug
Reading specs from
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2/collect2 -o
bug -L/home/yotta/software/lib/gcc-lib/mips64-unknown-elf/2.95.2
-L/home/yotta/software/mips64-unknown-elf/lib bug.o -lgcc -lgcc
-Ttarget.ld
--- objdump of bug.o ---
[ things to note in the objdump
[ size of .devtab section is 60 bytes (28 + 4 bytes pad + 4 bytes)
[ b starts at a 32 byte offset from the start of .devtab
[ the loop increments by 28 bytes (start+0x70)
bug.o: file format elf32-bigmips
Sections:
Idx Name Size VMA LMA File
off Algn
0 .text 00000000 0000000000000000 0000000000000000
00000034 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 0000000000000000 0000000000000000
00000034 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000
00000034 2**0
ALLOC
3 .reginfo 00000018 0000000000000000 0000000000000000
00000034 2**2
CONTENTS, READONLY, LINK_ONCE_SAME_SIZE
4 .mdebug 0000027c 0000000000000000 0000000000000000
0000004c 2**2
CONTENTS, READONLY, DEBUGGING
5 .text.f 00000024 0000000000000000 0000000000000000
000002c8 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
6 .devtab 0000003c 0000000000000000 0000000000000000
000002f0 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
7 .sdata 0000000a 0000000000000000 0000000000000000
00000330 2**3
CONTENTS, ALLOC, LOAD, DATA
8 .text._start 00000090 0000000000000000 0000000000000000
0000033c 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
Disassembly of section .text:
Disassembly of section .data:
Disassembly of section .text.f:
0000000000000000 <f>:
0: 27bdfff8 addiu $sp,$sp,-8
4: ffbe0000 sd $s8,0($sp)
8: 03a0f02d move $s8,$sp
c: 08000005 j 14 <f+0x14>
10: 0000102d move $v0,$zero
14: 03c0e82d move $sp,$s8
18: dfbe0000 ld $s8,0($sp)
1c: 03e00008 jr $ra
20: 27bd0008 addiu $sp,$sp,8
Disassembly of section .devtab:
0000000000000000 <a>:
...
8: 00000001 0x1
...
14: 00000001 0x1
...
0000000000000020 <b>:
20: 00000008 jr $zero
24: 00000008 jr $zero
28: 00000001 0x1
...
34: 00000001 0x1
38: 00000000 nop
Disassembly of section .sdata:
0000000000000000 <.sdata>:
0: 61000000 daddi $zero,$t0,0
4: 00000000 nop
8: Address 0x8 is out of bounds.
Disassembly of section .text._start:
0000000000000000 <_start>:
0: 27bdffc8 addiu $sp,$sp,-56
4: ffbf0030 sd $ra,48($sp)
8: ffbe0028 sd $s8,40($sp)
c: 03a0f02d move $s8,$sp
10: 00000000 nop
14: 3c020000 lui $v0,0x0
18: 64420000 daddiu $v0,$v0,0
1c: afc20020 sw $v0,32($s8)
20: 8fc20020 lw $v0,32($s8)
24: 3c030000 lui $v1,0x0
28: 64630000 daddiu $v1,$v1,0
2c: 14430003 bne $v0,$v1,3c <_start+0x3c>
30: 00000000 nop
34: 0800001f j 7c <_start+0x7c>
38: 00000000 nop
3c: 8fc20020 lw $v0,32($s8)
40: 8c43000c lw $v1,12($v0)
44: 0060f809 jalr $v1
48: 8fc40020 lw $a0,32($s8)
4c: 10400005 beqz $v0,64 <_start+0x64>
50: 00000000 nop
54: 8fc20020 lw $v0,32($s8)
58: 24030001 li $v1,1
5c: 0800001b j 6c <_start+0x6c>
60: ac430018 sw $v1,24($v0)
64: 8fc20020 lw $v0,32($s8)
68: ac400018 sw $zero,24($v0)
6c: 8fc20020 lw $v0,32($s8)
70: 2443001c addiu $v1,$v0,28
74: 08000008 j 20 <_start+0x20>
78: afc30020 sw $v1,32($s8)
7c: 03c0e82d move $sp,$s8
80: dfbf0030 ld $ra,48($sp)
84: dfbe0028 ld $s8,40($sp)
88: 03e00008 jr $ra
8c: 27bd0038 addiu $sp,$sp,56
So is this just by coding in eCos, or a compiler bug?
--
Chris Morrow YottaYotta Inc.
email: cmorrow@yottayotta.com
phone: (780) 439 9000 ext 227
web: http://www.yottayotta.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [ECOS] 64 bit mips arch, and __DEVTAB__
2000-07-12 15:15 [ECOS] 64 bit mips arch, and __DEVTAB__ Chris Morrow
@ 2000-07-12 15:24 ` Gary Thomas
2000-07-12 15:52 ` Chris Morrow
2000-07-12 16:50 ` Jonathan Larmour
0 siblings, 2 replies; 5+ messages in thread
From: Gary Thomas @ 2000-07-12 15:24 UTC (permalink / raw)
To: Chris Morrow; +Cc: ecos-discuss
On 12-Jul-2000 Chris Morrow wrote:
> I'm working on porting eCos to a 64 bit mips cpu and have encountered
> a problem with the DEVTAB_ENTRY macro defined in
> io/common/current/include/devtab.h. It would appear that gcc is aligning
> each piece of data added to the .devtab section on 8 byte boundries.
> This
> causes a space between entries and causes the loop in cyg_io_init() in
> io/commmon/current/iosys.c to fail.
>
> Depending on whether it is legitimate to assume that there is no padding
> for data objects added separately to a section with the section
> __attribute__,
> this may be a compiler issue rather than a eCos issue.
>
One concern [which we may have not thought about] is whether these data will
be properly aligned, even if the sizes match up.
Can you try adding the "aligned()" attribute to the devtab structure and see
what happens?
cyg_devtab_entry_t _l __attribute__ ((section(".devtab"),aligned(1)))
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] 64 bit mips arch, and __DEVTAB__
2000-07-12 15:24 ` Gary Thomas
@ 2000-07-12 15:52 ` Chris Morrow
2000-07-12 16:50 ` Jonathan Larmour
1 sibling, 0 replies; 5+ messages in thread
From: Chris Morrow @ 2000-07-12 15:52 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-discuss
Gary Thomas wrote:
>
> On 12-Jul-2000 Chris Morrow wrote:
> > I'm working on porting eCos to a 64 bit mips cpu and have encountered
> > a problem with the DEVTAB_ENTRY macro defined in
> > io/common/current/include/devtab.h. It would appear that gcc is aligning
> > each piece of data added to the .devtab section on 8 byte boundries.
> > This
> > causes a space between entries and causes the loop in cyg_io_init() in
> > io/commmon/current/iosys.c to fail.
> >
> > Depending on whether it is legitimate to assume that there is no padding
> > for data objects added separately to a section with the section
> > __attribute__,
> > this may be a compiler issue rather than a eCos issue.
> >
>
> One concern [which we may have not thought about] is whether these data will
> be properly aligned, even if the sizes match up.
>
> Can you try adding the "aligned()" attribute to the devtab structure and see
> what happens?
> cyg_devtab_entry_t _l __attribute__ ((section(".devtab"),aligned(1)))
Didn't make a difference.
--
Chris Morrow YottaYotta Inc.
email: cmorrow@yottayotta.com
phone: (780) 439 9000 ext 227
web: http://www.yottayotta.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] 64 bit mips arch, and __DEVTAB__
2000-07-12 15:24 ` Gary Thomas
2000-07-12 15:52 ` Chris Morrow
@ 2000-07-12 16:50 ` Jonathan Larmour
2000-07-12 17:00 ` Chris Morrow
1 sibling, 1 reply; 5+ messages in thread
From: Jonathan Larmour @ 2000-07-12 16:50 UTC (permalink / raw)
To: Gary Thomas; +Cc: Chris Morrow, ecos-discuss
Gary Thomas wrote:
>
> On 12-Jul-2000 Chris Morrow wrote:
> > I'm working on porting eCos to a 64 bit mips cpu and have encountered
> > a problem with the DEVTAB_ENTRY macro defined in
> > io/common/current/include/devtab.h. It would appear that gcc is aligning
> > each piece of data added to the .devtab section on 8 byte boundries.
[snip]
OOI I thought it would be interesting to see what gcc does here, with the
constructor lists. In config/mips/elf64.h it has:
#define ASM_OUTPUT_CONSTRUCTOR(FILE,NAME) \
do { \
ctors_section (); \
fprintf (FILE, "\t%s\t", (Pmode == SImode) ? ".word" : ".dword"); \
assemble_name (FILE, NAME); \
fprintf (FILE, "\n"); \
} while (0)
So it explicitly uses assembler. It might be interesting to look at bug.s
(generated by compiling with --save-temps ) and check that it is gcc adding
the alignments itself, and not the assembler. Perhaps Chris can send the
appropriate extract, since it will only take him a second.
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] 64 bit mips arch, and __DEVTAB__
2000-07-12 16:50 ` Jonathan Larmour
@ 2000-07-12 17:00 ` Chris Morrow
0 siblings, 0 replies; 5+ messages in thread
From: Chris Morrow @ 2000-07-12 17:00 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Gary Thomas, ecos-discuss
Jonathan Larmour wrote:
>
> Gary Thomas wrote:
> >
> > On 12-Jul-2000 Chris Morrow wrote:
> > > I'm working on porting eCos to a 64 bit mips cpu and have encountered
> > > a problem with the DEVTAB_ENTRY macro defined in
> > > io/common/current/include/devtab.h. It would appear that gcc is aligning
> > > each piece of data added to the .devtab section on 8 byte boundries.
> [snip]
>
> OOI I thought it would be interesting to see what gcc does here, with the
> constructor lists. In config/mips/elf64.h it has:
>
> #define ASM_OUTPUT_CONSTRUCTOR(FILE,NAME) \
> do { \
> ctors_section (); \
> fprintf (FILE, "\t%s\t", (Pmode == SImode) ? ".word" : ".dword"); \
> assemble_name (FILE, NAME); \
> fprintf (FILE, "\n"); \
> } while (0)
>
> So it explicitly uses assembler. It might be interesting to look at bug.s
> (generated by compiling with --save-temps ) and check that it is gcc adding
> the alignments itself, and not the assembler. Perhaps Chris can send the
> appropriate extract, since it will only take him a second.
>
> 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
bug.s as requested.
.file 1 "bug.c"
gcc2_compiled.:
__gnu_compiled_c:
.section .text.f,"ax",@progbits
.align 2
.globl f
.ent f
f:
.frame $fp,8,$31 # vars= 0, regs= 1/0, args= 0,
extra= 0
.mask 0x40000000,-8
.fmask 0x00000000,0
subu $sp,$sp,8
sd $fp,0($sp)
move $fp,$sp
move $2,$0
j $L2
$L2:
move $sp,$fp
ld $fp,0($sp)
addu $sp,$sp,8
j $31
.end f
.globl a
.section .devtab,"aw",@progbits
.align 3
.type a,@object
.size a,28
a:
.word $LC0
.word $LC0
.word 1
.word f
.word f
.word 1
.space 4
.sdata
.align 3
$LC0:
.ascii "a\000"
.globl b
.section .devtab,"aw",@progbits
.align 3
.type b,@object
.size b,28
b:
.word $LC1
.word $LC1
.word 1
.word f
.word f
.word 1
.space 4
.sdata
.align 3
$LC1:
.ascii "b\000"
.section .text._start,"ax",@progbits
.align 2
.globl _start
.ent _start
_start:
.frame $fp,56,$31 # vars= 8, regs= 2/0, args= 32,
extra= 0
.mask 0xc0000000,-8
.fmask 0x00000000,0
subu $sp,$sp,56
sd $31,48($sp)
sd $fp,40($sp)
move $fp,$sp
.set noreorder
nop
.set reorder
la $2,__DEVTAB__
sw $2,32($fp)
$L4:
lw $2,32($fp)
la $3,__DEVTAB_END__
bne $2,$3,$L7
j $L5
$L7:
lw $2,32($fp)
lw $3,12($2)
lw $4,32($fp)
jal $31,$3
beq $2,$0,$L8
lw $2,32($fp)
li $3,1 # 0x1
sw $3,24($2)
j $L6
$L8:
lw $2,32($fp)
sw $0,24($2)
$L9:
$L6:
lw $2,32($fp)
addu $3,$2,28
sw $3,32($fp)
j $L4
$L5:
$L3:
move $sp,$fp
ld $31,48($sp)
ld $fp,40($sp)
addu $sp,$sp,56
j $31
.end _start
--
Chris Morrow YottaYotta Inc.
email: cmorrow@yottayotta.com
phone: (780) 439 9000 ext 227
web: http://www.yottayotta.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-07-12 17:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-12 15:15 [ECOS] 64 bit mips arch, and __DEVTAB__ Chris Morrow
2000-07-12 15:24 ` Gary Thomas
2000-07-12 15:52 ` Chris Morrow
2000-07-12 16:50 ` Jonathan Larmour
2000-07-12 17:00 ` Chris Morrow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).