e7500 and gas and undefined and ...

[Ronald G Minnich]

OK, here is a fun one. secondary.inc moved to separate compilation as
secondary.S

It won't assemble:

secondary.s: Assembler messages:
secondary.s:87: Error: subtraction of two symbols in different sections
`gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 155
make: *** [secondary.o] Error 1

The problem code is:
gdtaddr:
        .word   gdt_end - gdt - 1 /* compute the table limit */
        .long   gdt                /* we know the offset */

Now, I have to sign off -- kids and all that -- and I'm hoping some of you
gas experts can puzzle this out. What should happen is that the gdtaddr in
secondary.S will have pointers to the gdt defined in crt0.S. Obviously
something needs fixing here so that the undefined references in
secondary.S are properly set up so you have a gdt in secondary.S. One
option is to include the gdt from the .inc file.

That *UND* section is kind of suspicious -- Maybe another directive is
needed?

ron

[Andrew Dennison]

secondary.inc used to be concatenated into the same file as the definition
of gdt (from entry32.inc). Maybe you just need to wrap gdt in EXT() to show
it's now an external reference to be resolved by the linker? ie:

[andrew@starbug src]$ diff arch/i386/smp/secondary.S.orig
arch/i386/smp/secondary.S
75,76c75,76
<       .word   gdt_end - gdt - 1 /* compute the table limit */
<       .long   gdt                /* we know the offset */
---
>   .word   EXT(gdt_end) - EXT(gdt) - 1 /* compute the table limit */
>   .long   EXT(gdt)                /* we know the offset */

labels like "gdtptr" are already exported in entry32.inc, so this may also
need to be done to "gdt" and "gdt_end" so the linker can resolve the
external references. ie

[andrew@starbug src]$ diff cpu/i386/entry32.inc.orig cpu/i386/entry32.inc
22c22,23
< gdt:
---
> .globl EXT(gdt)
> EXT(gdt):

64c65,66
< gdt_end:
---
> .globl EXT(gdt_end)
> EXT(gdt_end):

I'm still working out the structure of the code so I can look integrating
the SC520 and I haven't compiled these changes so I may be completely off
track...

Andrew
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ronald G Minnich
> Sent: Friday, 18 October 2002 9:04 AM
> To: [e-mail]
> Subject: e7500 and gas and undefined and ...
>
> OK, here is a fun one. secondary.inc moved to separate compilation as
> secondary.S
>
> It won't assemble:
>
> secondary.s: Assembler messages:
> secondary.s:87: Error: subtraction of two symbols in different sections
> `gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 155
> make: *** [secondary.o] Error 1
>
> The problem code is:
> gdtaddr:
>         .word   gdt_end - gdt - 1 /* compute the table limit */
>         .long   gdt                /* we know the offset */
>
> Now, I have to sign off -- kids and all that -- and I'm hoping some of you
> gas experts can puzzle this out. What should happen is that the gdtaddr in
> secondary.S will have pointers to the gdt defined in crt0.S. Obviously
> something needs fixing here so that the undefined references in
> secondary.S are properly set up so you have a gdt in secondary.S. One
> option is to include the gdt from the .inc file.
>
> That *UND* section is kind of suspicious -- Maybe another directive is
> needed?
>
> ron
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

Ronald G Minnich  writes:
> OK, here is a fun one. secondary.inc moved to separate compilation as
> secondary.S
>
> It won't assemble:
>
> secondary.s: Assembler messages:
> secondary.s:87: Error: subtraction of two symbols in different sections
> `gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 155
> make: *** [secondary.o] Error 1
>
> The problem code is:
> gdtaddr:
>         .word   gdt_end - gdt - 1 /* compute the table limit */
>         .long   gdt                /* we know the offset */

And it was:

gdtaddr:
        .word   gdt_limit       /* the table limit */
        .long   gdt             /* we know the offset */

And gdt_limit got rid of the problem.
And it is all defined in:
arch/i386/lib/c_start.S

This is from my break up of linuxbios into two seperately compiled
pieces so I could use upx on the code that runs from ram.

There are some issues with all of the ports working if I merged it as
is so I was delaying merging that bit.

I believe if I make the compression optional I can get around
the worst of the kinks.  The challenge is keeping the p4dc6 port
that uses cache as ram working.

Eric

[Ronald G Minnich]

On 17 Oct 2002, Eric W. Biederman wrote:
> gdtaddr:
>         .word   gdt_limit       /* the table limit */
>         .long   gdt             /* we know the offset */

I'll have to look, and find gdt_limit. This all started with gdt_limit
undefined :-)

thanks, Eric. I will try to get this one fixed and commit.

ron

upx

[Ronald G Minnich]

So upx is definitely worth it, right? Unless I misread it the decompressor
is assembly. We have a PPC port going on. I do see the 2-1 compression but
in 256KB we have oodles of room (with etherboot), so I'm just trying to
make sure the added complexity in the build is something we want.

Is it easily turned off?

thanks

ron
p.s. I know I promised not to distract you, sorry :-)

upx

Ronald G Minnich  writes:
> So upx is definitely worth it, right?

Yes.   It is much easier to put in lots of microcode updates
and things.  And we have lots of strings.

It is a very maintainable solution.
> Unless I misread it the decompressor is assembly.

And fits on one screen.  See also util/nrv2b which has
the C compressor decompressor.  I put it in crt0.base in my tree

The data structures are all heavily tuned so you can have a very
small and simple assembly decopressor.  And I think you can
dig non-x86 ports out of the main upx tree.
> We have a PPC port going on. I do see the 2-1 compression but
> in 256KB we have oodles of room (with etherboot), so I'm just trying to
> make sure the added complexity in the build is something we want.

Except for the decompression step all I did was clearly seperate
the code that can assume it has ram, from the painful assemly include,
execute from rom code that gets us there.

It actually reduces complexity in several places in the linker script,
as we don't have to tell the linker put the code here, but actually
set it up so it executes there.

As for size for the longest time it has been my goal to keep linuxbios
small enough that I can fit LinuxBIOS and etherboot into 64KB.  We are
quickly going from being the overly large solution to a solution for
a smaller BIOS.  And if we can do it why not?
> Is it easily turned off?

Yes.  You do a memcpy instead of decompression.  I just haven't had 
time to write the code to make it conditional yet.
> thanks
>
> ron
> p.s. I know I promised not to distract you, sorry :-)

So long as I don't have to do the merger a little distraction now and
again is o.k.  And getting some discussion and code review going over
my code is probably a good side benefit.

Eric

upx

[Ronald G Minnich]

So how about a
CONFIG_UPX

to turn that feature on and off? sound reasonable?

ron

upx

Ronald G Minnich  writes:
> So how about a
> CONFIG_UPX
>
> to turn that feature on and off? sound reasonable?

I'd rather see CONFIG_COMPRESS as that is a little more
obvious what it does, and no where else do we actually mention
UPX, but instead we talk about the ucl compression library and
the nrv2b compresion algorithm.

But the name is the easy part....

Eric

upx

[Ronald G Minnich]

CONFIG_COMPRESS it is. Now for the hard part :-)

ron