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 (<jrt...@jrtc27.com>) escribió: > On 15 Feb 2019, at 13:21, Samuel Thibault <samuel.thiba...@gnu.org> 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
