Re: Error with gnumach compilation
> > I don't recommend leaving it up for later like this, or at least put a > fat XXX that you will remember. > Thanks for the tip. I'll add a TODO label in the blocks to replace. This work (to recover old APIC structures and cpu_number()) is a previous step to implement cpus enumeration. The real LAPIC address will be get from ACPI tables during cpus enumeration, which will be implemented soon, El vie., 15 feb. 2019 a las 17:23, Samuel Thibault () escribió: > Almudena Garcia, le ven. 15 févr. 2019 17:11:04 +0100, a ecrit: > > And now It compiles. Probably It will not work yet, because the APIC > Table > > address could be not correct, but these can be fixed in other time. > > I don't recommend leaving it up for later like this, or at least put a > fat XXX that you will remember. > > This kind of leaving problems under the carpet *always* bite sooner or > later (hopefully sooner so that you remember about it). > > Getting the thing to compile is a good thing, but writing the correct > things is a really important one before proceeding further, notably for > such ground bits. > > Samuel >
Re: Error with gnumach compilation
Almudena Garcia, le ven. 15 févr. 2019 17:11:04 +0100, a ecrit: > And now It compiles. Probably It will not work yet, because the APIC Table > address could be not correct, but these can be fixed in other time. I don't recommend leaving it up for later like this, or at least put a fat XXX that you will remember. This kind of leaving problems under the carpet *always* bite sooner or later (hopefully sooner so that you remember about it). Getting the thing to compile is a good thing, but writing the correct things is a really important one before proceeding further, notably for such ground bits. Samuel
Re: Error with gnumach compilation
Solved. I merged imps/cpu_number.h code in kern/cpu_number.h and i386/i386/cpu_number.h Also, I removed APIC_LOCAL_APIC_ID symbol, which has not defined in the code. And now It compiles. Probably It will not work yet, because the APIC Table address could be not correct, but these can be fixed in other time. https://github.com/AlmuHS/GNUMach_SMP/commits/wip El vie., 15 feb. 2019 a las 16:04, Richard Braun () escribió: > On Fri, Feb 15, 2019 at 03:56:03PM +0100, Almudena Garcia wrote: > > After a couple of changes, this assembly errors disappeared, but now It > > show newer errors in the linker step. > > There's a "trick" in the building process that cherry picks functions > from the C library when they're undefined in the kernel (correct me if > I'm wrong about this). But when a symbol is undefined in both the kernel > and the C library, the link just fails. The symbol in question here is > APIC_LOCAL_APIC_ID. The fix should be obvious. > > -- > Richard Braun >
Re: Error with gnumach compilation
On Fri, Feb 15, 2019 at 03:56:03PM +0100, Almudena Garcia wrote: > After a couple of changes, this assembly errors disappeared, but now It > show newer errors in the linker step. There's a "trick" in the building process that cherry picks functions from the C library when they're undefined in the kernel (correct me if I'm wrong about this). But when a symbol is undefined in both the kernel and the C library, the link just fails. The symbol in question here is APIC_LOCAL_APIC_ID. The fix should be obvious. -- Richard Braun
Re: Error with gnumach compilation
On Fri, Feb 15, 2019 at 02:33:55PM +0100, Almudena Garcia wrote: > I removed this macro tonight, to write a better solution. > > https://github.com/AlmuHS/GNUMach_SMP/commit/342b7d62168bcaca944d01c0550b899da5d7f0c5 > > I've got to enabled correctly this macro, and feels that CPU_NUMBER > assembly macro is enabled, but compiler shows another error > > ../i386/i386/cswitch.S: Mensajes del ensamblador: > ../i386/i386/cswitch.S:46: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:64: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:116: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» You should recognize, without others telling you, that the very least would be to switch your locale so that the error messages can be understood by everyone on this list, even if those particular ones are obvious. -- Richard Braun
Re: Error with gnumach compilation
On 15 Feb 2019, at 13:33, Almudena Garcia wrote: > El vie., 15 feb. 2019 a las 14:28, James Clarke () > escribió: >> On 15 Feb 2019, at 13:21, Samuel Thibault wrote: >> > >> > Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit: >> >> This is defined in imps/cpu_number.h , included in kern/cpu_number.h >> > >> > cswitch.S includes i386/cpu_number.h, not kern/cpu_number.h >> > >> > Really, make sure it gets defined, that's very most probably the issue, >> > or else it's the CPU_NUMBER macro which is not actually valid assembly. >> >> Well, I had checked before sending my email, and i386/cpu_number.h does not >> define CPU_NUMBER, though I was unaware of kern/cpu_number.h. The latter does >> define a cpu_number function, but it's a C header, not for use in assembly. >> Your `smp` branch fixes this in [1] by making CPU_NUMBER a macro that calls >> cpu_number (though I might suggest that you make the macro do nothing for >> NCPUS==1). Honestly, this is not a hard bug to find, it took all of a few >> minutes for me. You've had more than enough information from us to pinpoint >> the >> problem; this mailing list is really not for simple programming questions >> like >> this. >> >> James >> >> [1] >> https://github.com/AlmuHS/GNUMach_SMP/commit/371df36e565f4408737948ccc3d25acf2e1ccb57 > > I removed this macro tonight, to write a better solution. > > https://github.com/AlmuHS/GNUMach_SMP/commit/342b7d62168bcaca944d01c0550b899da5d7f0c5 > > I've got to enabled correctly this macro, and feels that CPU_NUMBER assembly > macro is enabled, but compiler shows another error > > ../i386/i386/cswitch.S: Mensajes del ensamblador: > ../i386/i386/cswitch.S:46: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:64: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:116: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» This is now getting really tiring. It's complaining about both operands to + being undefined, on lines where you're using CPU_NUMBER. CPU_NUMBER is defined by you as: #define CPU_NUMBER(reg) \ movzbl APIC_LOCAL_VA+APIC_LOCAL_UNIT_ID+3,reg Which of those operands for + look like they could be undefined symbols to you? Seriously, you need to learn to fix these things for yourself. James
Re: Error with gnumach compilation
I removed this macro tonight, to write a better solution. https://github.com/AlmuHS/GNUMach_SMP/commit/342b7d62168bcaca944d01c0550b899da5d7f0c5 I've got to enabled correctly this macro, and feels that CPU_NUMBER assembly macro is enabled, but compiler shows another error ../i386/i386/cswitch.S: Mensajes del ensamblador: ../i386/i386/cswitch.S:46: Error: operandos inválidos (secciones *UND* y *UND*) para «+» ../i386/i386/cswitch.S:64: Error: operandos inválidos (secciones *UND* y *UND*) para «+» ../i386/i386/cswitch.S:116: Error: operandos inválidos (secciones *UND* y *UND*) para «+» El vie., 15 feb. 2019 a las 14:28, James Clarke () escribió: > On 15 Feb 2019, at 13:21, Samuel Thibault wrote: > > > > Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit: > >> This is defined in imps/cpu_number.h , included in kern/cpu_number.h > > > > cswitch.S includes i386/cpu_number.h, not kern/cpu_number.h > > > > Really, make sure it gets defined, that's very most probably the issue, > > or else it's the CPU_NUMBER macro which is not actually valid assembly. > > Well, I had checked before sending my email, and i386/cpu_number.h does not > define CPU_NUMBER, though I was unaware of kern/cpu_number.h. The latter > does > define a cpu_number function, but it's a C header, not for use in assembly. > Your `smp` branch fixes this in [1] by making CPU_NUMBER a macro that calls > cpu_number (though I might suggest that you make the macro do nothing for > NCPUS==1). Honestly, this is not a hard bug to find, it took all of a few > minutes for me. You've had more than enough information from us to > pinpoint the > problem; this mailing list is really not for simple programming questions > like > this. > > James > > [1] > https://github.com/AlmuHS/GNUMach_SMP/commit/371df36e565f4408737948ccc3d25acf2e1ccb57
Re: Error with gnumach compilation
On 15 Feb 2019, at 13:21, Samuel Thibault wrote: > > Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit: >> This is defined in imps/cpu_number.h , included in kern/cpu_number.h > > cswitch.S includes i386/cpu_number.h, not kern/cpu_number.h > > Really, make sure it gets defined, that's very most probably the issue, > or else it's the CPU_NUMBER macro which is not actually valid assembly. Well, I had checked before sending my email, and i386/cpu_number.h does not define CPU_NUMBER, though I was unaware of kern/cpu_number.h. The latter does define a cpu_number function, but it's a C header, not for use in assembly. Your `smp` branch fixes this in [1] by making CPU_NUMBER a macro that calls cpu_number (though I might suggest that you make the macro do nothing for NCPUS==1). Honestly, this is not a hard bug to find, it took all of a few minutes for me. You've had more than enough information from us to pinpoint the problem; this mailing list is really not for simple programming questions like this. James [1] https://github.com/AlmuHS/GNUMach_SMP/commit/371df36e565f4408737948ccc3d25acf2e1ccb57
Re: Error with gnumach compilation
Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit: > This is defined in imps/cpu_number.h , included in kern/cpu_number.h cswitch.S includes i386/cpu_number.h, not kern/cpu_number.h Really, make sure it gets defined, that's very most probably the issue, or else it's the CPU_NUMBER macro which is not actually valid assembly. Samuel
Re: Error with gnumach compilation
This is defined in imps/cpu_number.h , included in kern/cpu_number.h
I've disabled the ASSEMBLY macro, but the error continues
El vie., 15 feb. 2019 a las 3:20, James Clarke ()
escribió:
> On 15 Feb 2019, at 00:48, Almudena Garcia
> wrote:
> >
> > Hi all:
> >
> > I'm doing some experiments with my GNUMach SMP fork, and now I'm trying
> to recover old imps files.
> >
> > But, when I try to compile this, It shows an assembly error in cswitch.S
> (attach file)
> >
> > ../i386/i386/cswitch.S: Mensajes del ensamblador:
> > ../i386/i386/cswitch.S:42: Error: carácter inválido '(' en el mnemónico
> > ../i386/i386/cswitch.S:60: Error: carácter inválido '(' en el mnemónico
> > ../i386/i386/cswitch.S:112: Error: carácter inválido '(' en el mnemónico
> > make: *** [Makefile:4804: i386/i386/cswitch.o] Error 1
> >
> > My full code is here: https://github.com/AlmuHS/GNUMach_SMP/tree/wip
> >
> > Can you help me to find the error?
>
> Your cpu_number.h doesn't define CPU_NUMBER for NCPUS > 1.
>
> James
>
>
Re: Error with gnumach compilation
Almudena Garcia, le ven. 15 févr. 2019 01:48:36 +0100, a ecrit:
> ../i386/i386/cswitch.S:42: Error: carácter inválido '(' en el mnemónico
This looks like the CPU_NUMBER macro missing being defined to put the
CPU number into eax.
Samuel
