haker_fox 61 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 2 hours ago, jcxz said: Не передаётся только номер после SVC. Так а кто заставляет его использовать? Я под аргументом и подразумевал номер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 1 минуту назад, haker_fox сказал: регистрах нет информации об аргументе. Да. Но вы знаете текущий стек и его указатель. Идете туда, вычитываете стандартный кадр, а уже в нем вся подноготная. 2 минуты назад, haker_fox сказал: Я под аргументом и подразумевал номер. В стековом кадре будет значение PC. Пошаманив со смещением найдете адрес инструкции swс, а уже в ее теле будет номер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 9 минут назад, haker_fox сказал: Ну так я то про ассемблер. Я не использвал вызов и обработку SVC из СИ. Так вот, при вызове прерывания из ассемблерного кода, мы попадаем в вектор SVC, но в регистрах нет информации об аргументе. Так занесите их туда. Перед вызовом. Точно так же как при вызове обычной функции. Хоть си хоть асм - какая разница? Механизм один. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 9 minutes ago, adnega said: В стековом кадре будет значение PC. Пошаманив со смещением найдете адрес инструкции swс, а уже в ее теле будет номер. У меня такое ощущение, что я об этом и говорил 2 minutes ago, jcxz said: Так занесите их туда. Простите, зачем? Если этот номер (ранее мной неточно названный аргументом), можно найти в обработчике из кода команды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 5 минут назад, haker_fox сказал: У меня такое ощущение, что я об этом и говорил SVCHandler: tst lr, #4 ite eq mrseq r3, msp mrsne r3, psp ldr r1, [r3, #24] ldrb r0, [r1, #-2] cmp r0, #2 it hi bxhi lr tbb [pc, r0] svc_func_table: .byte ((svc_func_timer_set - svc_func_table) / 2) .byte ((svc_func_timer_tick - svc_func_table) / 2) svc_func_timer_set: ldr r0, [r3, #0] ldr r1, [r3, #4] str r1, [r0] str r1, [r3, #0] bx lr svc_func_timer_tick: ldr r0, [r3, #0] ldr r1, [r0] add r1, #10 str r1, [r0] str r1, [r3, #0] bx lr .global svc_timer_set svc_timer_set: svc 0 bx lr .global svc_timer_tick svc_timer_tick: svc 1 bx lr Вместо тысячи слов... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 11 минут назад, adnega сказал: Спора никакого нет. Я изначально сказал, что SVCall - это исключение, и для него справедливы все правила исключений. Похоже Вы так ничего и не поняли... SVC - это СИНХРОННОЕ исключение. В прошлый раз выделил, сейчас ещё и напишу большими буквами. Именно из-за того что оно синхронное, а не асинхронное (как некоторые другие) оно и выполняется именно так: вызывает блокировку если его невозможно выполнить немедленно. Для асинхронных исключений это правило не действует. Какие исключения являются синхронными, а какие нет - смотрите мануал на ядро - там есть табличка. Так что "всех правил" для исключений - нет, они разные. 11 минут назад, adnega сказал: Вы же начали обсуждать частные случаи. Вот их и обсуждаем. Я вообще-то всего-лишь сказал, что если хочется вызывать SVC вместо функций, то запрещать fault-ы нелья: 2 часа назад, jcxz сказал: Есть ограничение вызова SVC от обычных функций: обычные можно вызывать при запрещённых fault-ах, но если так попытаться сделать с SVC, то очень поплохеет. Против чего Вы вдруг начали спорить: 2 часа назад, adnega сказал: Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. 11 минут назад, adnega сказал: Насколько вам известно, исключение SVCall можно возбудить двумя способами: соответствующей инструкцией (синхронный) и через pending-бит NVIC (асинхронный). Мне это неизвестно. Где я такое писал??? Да и разработчикам ядра Cortex-M - тоже неизвестно. Объясните - как именно можно вызвать SVC "через pending-бит NVIC (асинхронный)."? Ещё раз: SVC - это синхронное исключение. Ну не бывает оно асинхронным! 11 минут назад, adnega сказал: Я утверждаю, что асинхронный вызов SVCall не должен никак повредить системе даже с "запрещенными" fault`ами. А вы? Мне неизвестно ядро где SVC - асинхронный. Просветите нас о каком ядре ведёте речь??? В Cortex-M вызов SVC при запрещённых (через FAULTMASK фаултах приведёт к блокировке CPU). Это по вашему значит "не должен никак повредить системе"? 11 минут назад, adnega сказал: Замаскировать NMI-обработчик невозможно. Отключить все возбудители NMI - даже обсуждать не стоит в силу очевидности. Ну ясно - значит вам просто охота поспорить не важно о чём..... 38 минут назад, haker_fox сказал: Я под аргументом и подразумевал номер. "Аргумент" - это то что можно передать в функцию. Номер после слова SVC - это часть команды SVC. Это не только моё мнение, но и авторов IAR например. См. "#pragma swi_number". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 38 минут назад, haker_fox сказал: Простите, зачем? Если этот номер (ранее мной неточно названный аргументом), можно найти в обработчике из кода команды. Затем что кто-то говорил: 3 часа назад, haker_fox сказал: т.е. вызыван будет обработчик по адресу SVC. Аргументы при этом через регистры не передаются!!! Передавать аргументы в обработчик SVC можно точно также как в обычных функциях. По-крайней мере те аргументы, что влезают в регистры. Никакое тело команды не нужно. И если рассматривать интерфейс IAR для SVC-функций - там именно так и поступают: #pragma swi_number=SVCF_trap0 __swi void trap1(u32); #pragma swi_number=SVCF_trap1 __swi void trap2(u32, u32); #pragma swi_number=SVCF_trap2 __swi void trap3(u32, u32, u32); Итого объявляется 3 функции: trap1(), trap2(), trap3(). Вроде всё предельно ясно. Всё передаётся через регистры. А разные номера SVC - это разные функции. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 22 минуты назад, jcxz сказал: Ещё раз: SVC - это синхронное исключение. Ну не бывает оно асинхронным! Использовать SVC в асинхронном виде - смысла, конечно же, лишено, но. Есть такой регистр System handler control and state register (SCB_SHCSR). У этого регистра есть rw-бит с номером 15: Bit 15 SVCALLPENDED: SVC call pending bit, reads as 1 if exception is pending. Описание бита имеет такую сноску: Pending bits, read as 1 if the exception is pending, or as 0 if it is not pending. You can write to these bits to change the pending status of the exceptions. Осмелюсь предположить, что запись в 1 бита 15 регистра SCB_SHCSR должно спровоцировать исключение с обработчиком SVCall. Повторюсь, практического смысла в этом ноль, проверять - не проверял, но истина дороже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба Проверил - прекрасно возбуждается. void SVCHandler(void) { con_str("{SVCall}\n\r"); con_start(); } void func_scall(void *p) { asm("svc #0"); } void func_acall(void *p) { SCB->SHCSR = (1 << 15); } Имею лог: Цитата >scall {SVCall} >acall {SVCall} > Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 18 минут назад, adnega сказал: Осмелюсь предположить, что запись в 1 бита 15 регистра SCB_SHCSR должно спровоцировать исключение с обработчиком SVCall. И что? Осмелюсь предположить (исходя из принципа работы всех синхронных исключений), что если в данный момент SVC можно выполнить, то оно выполнится и бит снимется тут же, а если выполнить нельзя - CPU заблокируется, а этот бит установится (а может просто ничего не произойдёт). Да и при чём тут этот бит запроса? Разговор вроде был про команду SVC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 7 минут назад, jcxz сказал: Да и при чём тут этот бит запроса? Разговор вроде был про команду SVC. Нет - разговор был про SVCall-исключение. Про асинхронность SVCall вы не знали - рад, что вы для себя сегодня открыли что-то новое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 2 минуты назад, adnega сказал: Про асинхронность SVCall вы не знали - рад, что вы для себя сегодня открыли что-то новое. Откройте наконец-то мануал на ядро Cortex-M и найдите таблицу: "Table 2-16 Properties of the different exception types". Найдите в ней столбец "Activation". Если не согласны с ней - спорьте с разработчиками архитектуры. Мне спорить с Вами - пустая трата времени, Вы же лучше знаете как работает Cortex-M лучше тех кто его разрабатывал. 11 минут назад, adnega сказал: Нет - разговор был про SVCall-исключение. Да я уже понял что передёргивать Вы умеете. И бессмысленно тыкать в историю этого треда - любой может прочитать о чём был разговор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба Только что, jcxz сказал: Если не согласны с ней - спорьте с разработчиками архитектуры. Я вас понял. void func_scall(void *p) { asm("svc #0"); } void func_acall(void *p) { SCB->SHCSR = (1 << 15); } if(fcall) { fcall = 0; asm("cpsid f"); SCB->SHCSR = (1 << 15); } if(xcall) { xcall = 0; asm("cpsid f"); asm("svc #0"); } Исход такой: Цитата >scall {SVCall} - обычный синхронный вызов >acall {SVCall} - "недокументированный" асинхронный вызов >fcall >{SVCall} - запретили fault`ы и спровоцировали "недокументированный" асинхронный вызов. Все ок. xcall - словили блокировку. Мое представление архитектуры по этому вопросу оказывается полностью соответствует поведению железа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 18 минут назад, adnega сказал: Мое представление архитектуры по этому вопросу оказывается полностью соответствует поведению железа. К чему эта портянка что выше? о чём она и для чего? ничего не понятно... Так Вы до сих пор считаете что: 4 часа назад, adnega сказал: Иначе: можно ли вызвать исключение из исключения? Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял. Так при чём или не причём запрет fault-ов? Вам уже удалось вызвать SVC при запрещённых fault-ах? Приведите код который это позволяет сделать. Чтобы мы могли его проверить. Именно код позволяющий сделать вызов обработчика SVC при запрещенных исключениях, а не ту невразумительную портянку, что выше. Пускай даже через этот бит SHCSR, а не через обсуждавшуюся команду. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 5 минут назад, jcxz сказал: Именно код позволяющий сделать вызов обработчика SVC при запрещенных исключениях asm("cpsid f"); SCB->SHCSR = (1 << 15); Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться