[9fans] Assembler weirdness?

[9fans] Assembler weirdness?

[Pietro Gagliardi]

Hello. I'm trying to switch from GCC/NASM to the good old Plan 9 tools
to get a simple kernel I'm writing compiled and working with 9load
(which fortunately is Multiboot-compliant). But there is one file - an
8a-ized hand-me-down interrupt service routine array - that is causing
problems. Running

	8a /n/sources/contrib/pietro/jamesmol.s

yields the errors in /n/sources/contrib/pietro/jamesmol.out. But if I
first preprocess with cpp(1), which produces /n/sources/contrib/pietro/
jamesmol.fixed, everything works fine with 8a. What's wrong?

- Pietro

PS - This is when I hate macros.

Re: [9fans] Assembler weirdness?

[erik quanstrom]

> Hello. I'm trying to switch from GCC/NASM to the good old Plan 9 tools
> to get a simple kernel I'm writing compiled and working with 9load
> (which fortunately is Multiboot-compliant). But there is one file - an
> 8a-ized hand-me-down interrupt service routine array - that is causing
> problems. Running
>
> 	8a /n/sources/contrib/pietro/jamesmol.s
>
> yields the errors in /n/sources/contrib/pietro/jamesmol.out. But if I
> first preprocess with cpp(1), which produces /n/sources/contrib/pietro/
> jamesmol.fixed, everything works fine with 8a. What's wrong?
>
> - Pietro
>
> PS - This is when I hate macros.

i believe 8c disapproves of string pasting.

- erik

Re: [9fans] Assembler weirdness?

[Pietro Gagliardi]

You mean ##? Okay, but since 8a doesn't have an option to issue the
standard C preprocessor (cpp(1) - 8c has -p), I'll see what I can do.

On May 17, 2008, at 9:44 PM, erik quanstrom wrote:

>> Hello. I'm trying to switch from GCC/NASM to the good old Plan 9
>> tools
>> to get a simple kernel I'm writing compiled and working with 9load
>> (which fortunately is Multiboot-compliant). But there is one file -
>> an
>> 8a-ized hand-me-down interrupt service routine array - that is
>> causing
>> problems. Running
>>
>> 	8a /n/sources/contrib/pietro/jamesmol.s
>>
>> yields the errors in /n/sources/contrib/pietro/jamesmol.out. But if I
>> first preprocess with cpp(1), which produces /n/sources/contrib/
>> pietro/
>> jamesmol.fixed, everything works fine with 8a. What's wrong?
>>
>> - Pietro
>>
>> PS - This is when I hate macros.
>
> i believe 8c disapproves of string pasting.
>
> - erik
>
>

[9fans] Linker weirdness? (was: Assembler weirdness?)

[Pietro Gagliardi]

I fixed it by specifying in the mkfile to convert jamesmol.s to
jmfixed.s or something.

But now when I go to link I get these weird errors about undefined
symbols in a function that they are not even related to.

source: /n/sources/contrib/pietro/pgos.tar
error list: /n/sources/contrib/pietro/pgos.err

And yes, I plan to use the a.out(6). But now it just takes raw binary.

On May 17, 2008, at 10:21 PM, Pietro Gagliardi wrote:

> You mean ##? Okay, but since 8a doesn't have an option to issue the
> standard C preprocessor (cpp(1) - 8c has -p), I'll see what I can do.
>
> On May 17, 2008, at 9:44 PM, erik quanstrom wrote:
>
>>> Hello. I'm trying to switch from GCC/NASM to the good old Plan 9
>>> tools
>>> to get a simple kernel I'm writing compiled and working with 9load
>>> (which fortunately is Multiboot-compliant). But there is one file
>>> - an
>>> 8a-ized hand-me-down interrupt service routine array - that is
>>> causing
>>> problems. Running
>>>
>>> 	8a /n/sources/contrib/pietro/jamesmol.s
>>>
>>> yields the errors in /n/sources/contrib/pietro/jamesmol.out. But
>>> if I
>>> first preprocess with cpp(1), which produces /n/sources/contrib/
>>> pietro/
>>> jamesmol.fixed, everything works fine with 8a. What's wrong?
>>>
>>> - Pietro
>>>
>>> PS - This is when I hate macros.
>>
>> i believe 8c disapproves of string pasting.
>>
>> - erik
>>
>>
>
>

Re: [9fans] Linker weirdness? (was: Assembler weirdness?)

[Bruce Ellis]

please keep this off the list. you fixing something for a change.is as
interesting as my puppy shiiting outside.

good doggy,

brucee

On 5/18/08, Pietro Gagliardi <pietro10@mac.com> wrote:
> I fixed it by specifying in the mkfile to convert jamesmol.s to jmfixed.s or
> something.
>
> But now when I go to link I get these weird errors about undefined symbols
> in a function that they are not even related to.
>
> source: /n/sources/contrib/pietro/pgos.tar
> error list: /n/sources/contrib/pietro/pgos.err
>
> And yes, I plan to use the a.out(6). But now it just takes raw binary.
>
> On May 17, 2008, at 10:21 PM, Pietro Gagliardi wrote:
>
> > You mean ##? Okay, but since 8a doesn't have an option to issue the
> standard C preprocessor (cpp(1) - 8c has -p), I'll see what I can do.
> >
> > On May 17, 2008, at 9:44 PM, erik quanstrom wrote:
> >
> >
> > >
> > > > Hello. I'm trying to switch from GCC/NASM to the good old Plan 9 tools
> > > > to get a simple kernel I'm writing compiled and working with 9load
> > > > (which fortunately is Multiboot-compliant). But there is one file - an
> > > > 8a-ized hand-me-down interrupt service routine array - that is causing
> > > > problems. Running
> > > >
> > > >        8a /n/sources/contrib/pietro/jamesmol.s
> > > >
> > > > yields the errors in
> /n/sources/contrib/pietro/jamesmol.out. But if I
> > > > first preprocess with cpp(1), which produces
> /n/sources/contrib/pietro/
> > > > jamesmol.fixed, everything works fine with 8a. What's wrong?
> > > >
> > > > - Pietro
> > > >
> > > > PS - This is when I hate macros.
> > > >
> > >
> > > i believe 8c disapproves of string pasting.
> > >
> > > - erik
> > >
> > >
> > >
> >
> >
> >
>
>
>

Re: [9fans] Linker weirdness?

[Robert William Fuller]

Bruce Ellis wrote:
> please keep this off the list. you fixing something for a change.is as
> interesting as my puppy shiiting outside.
>
> good doggy,
>
> brucee

Unlike your waste of bandwidth?  Bad kitty!  Don't pee on the list!

Re: [9fans] Linker weirdness?

[Bruce Ellis]

Nice to get some technical input from you.

brucee

On 5/18/08, Robert William Fuller <hydrologiccycle@gmail.com> wrote:
> Bruce Ellis wrote:
> > please keep this off the list. you fixing something for a change.is as
> > interesting as my puppy shiiting outside.
> >
> > good doggy,
> >
> > brucee
> >
>
> Unlike your waste of bandwidth?  Bad kitty!  Don't pee on the list!
>
>
>

Re: [9fans] Linker weirdness? (was: Assembler weirdness?)

[erik quanstrom]

> 8l -T0x100000 -o 8.out boot.8 cpuid.8 floppy.8 gdt.8 halt.8 harddisk.8 interrupt.8 jmtrue.8 keyboard.8 memory.8 multitask.8 onlyin.8 pci.8 syscall.8 time.8 timer.8 tone.8 video.8 x86.8 ../port/libpgosport.a
> initnonport: incompatible type signatures 4c81a129(gdt.8) and 97da8762(x86.8) for initgdt
> main: incompatible type signatures 4c81a129(timer.8) and 951b2e20(../port/libpgosport.a(main)) for inittimer
> simplelang: np: not defined
> simplelang: apm: not defined
> simplelang: gdt: not defined

apoligies in advance for addressing the actual question.

the default CFLAGS were changed recently on sources.  the -T flag was added to the
defaults.  this adds type signatures to .$O files.  without -T type signatures are left
blank.  the linker expects either all the signatures for a particular symbol to match
or to be blank.

incompatable signatures happen when the same external symbol is declared with
different types in different source files.  the linker is picky.  "uint" and "int" are not
compatable.

- erik

Re: [9fans] Linker weirdness? (was: Assembler weirdness?)

[Pietro Gagliardi]

Thanks for the typing tip. It turns out that I used x+0(SB) instead of
x+0(FP) for some of the arguments to a functions. Now to test.

On May 18, 2008, at 8:02 AM, erik quanstrom wrote:

>> 8l -T0x100000 -o 8.out boot.8 cpuid.8 floppy.8 gdt.8 halt.8
>> harddisk.8 interrupt.8 jmtrue.8 keyboard.8 memory.8 multitask.8
>> onlyin.8 pci.8 syscall.8 time.8 timer.8 tone.8 video.8 x86.8 ../
>> port/libpgosport.a
>> initnonport: incompatible type signatures 4c81a129(gdt.8) and
>> 97da8762(x86.8) for initgdt
>> main: incompatible type signatures 4c81a129(timer.8) and
>> 951b2e20(../port/libpgosport.a(main)) for inittimer
>> simplelang: np: not defined
>> simplelang: apm: not defined
>> simplelang: gdt: not defined
>
> apoligies in advance for addressing the actual question.
>
> the default CFLAGS were changed recently on sources.  the -T flag
> was added to the
> defaults.  this adds type signatures to .$O files.  without -T type
> signatures are left
> blank.  the linker expects either all the signatures for a
> particular symbol to match
> or to be blank.
>
> incompatable signatures happen when the same external symbol is
> declared with
> different types in different source files.  the linker is picky.
> "uint" and "int" are not
> compatable.
>
> - erik
>
>

Re: [9fans] Linker weirdness? (was: Assembler weirdness?)

[Richard Miller]

> But now when I go to link I get these weird errors about undefined
> symbols in a function that they are not even related to.

Yes, the linker is being weird or at least misleading when it
reports undefined symbols:

> simplelang: np: not defined
> simplelang: apm: not defined
> simplelang: gdt: not defined

It is telling you which procedure it was processing when it detected
the error, not necessarily which procedure was responsible for the
error.  Because it is not known which symbols are undefined until all
object files have been seen, the "not defined" messages are all labelled
with the last procedure of the last object file to be processed.

You can get more useful information by doing something like:

term%  nm *.8 ../port/*.a | grep ' ((np)|(apm)|(gdt))$'
gdt.8: d gdt
onlyin.8: U apm
onlyin.8: U gdt
onlyin.8: U np

This tells you that gdt is actually there but it's been declared as
a static (local) label; and np and apm are referenced in onlyin.8
but not defined anywhere.