Центр информации по операционным системам: Форумы / GNU/Linux / sparc32: вопрос по alignment!

Центр информации по операционным системам :: Форумы :: Операционные системы :: GNU/Linux		<< Предыдущая тема \| Следующая тема >>
sparc32: вопрос по alignment!

Переход на страницу [1] 2 3
Модераторы: Roman I Khimov, Wanderer, Dron

Автор Добавил

vv40in

Четверг 09.10.2008 17:06

ID пользователя #1076

Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62

здравствуйте!

выдержка из sparcv8.pdf (p.46):

Alignment Restrictions:
Halfword accesses must be aligned on a 2-byte boundary, word accesses (which include instruction fetches) must be aligned on a 4-byte boundary, and doubleword accesses must be aligned on an 8-byte boundary. An improperly aligned address causes a load or store instruction to generate a mem_address_not_aligned trap.

а то, о чем говорится ниже - найдено в ядре Linux!
в моем случае, как я вижу из лога, 8-байтная величина (i_size из struct inode) располагается по адресу не кратному 8. после обращения к такой переменной происходит зависание.

даже если аллокатор выделит память с указателем кратным 8, то при копировании такой структуры в др.область, которая не выровнена по 8, при обращении к переменной опять же произойдет трап!

я не специалист в sparc, и не знаю возможно ли обработать trap так, чтобы заполнить переменную правильным значением и вернуться на следующий шаг.
(да и вообще не знаю как писать обработчики tarp-ов

)

и я уверен, что 64-битная проблема встретится и дальше.
спаркологи! поможите чем можете! что мне делать?
как добиться загрузки ядра?

Наверх

Dron

Пятница 10.10.2008 09:42

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Не может быть что в Sparc linux все так плохо... он что вообще не сопровождается?

Проблему можно попытаться вылечить, если ты определишь где это происходит. Скажи функцию.

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев

Наверх

vv40in

Пятница 10.10.2008 11:30

ID пользователя #1076

Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62

linux snapgear (ftp://gaisler.com/gaisler.com/linux/linux-2.6/snapgear/snapgear-2.6-p36c.tar.bz2).
linux-2.6.21.1/fs/inode.c
функция inode* alloc_node(super_block*).

Наверх

Dron

Пятница 10.10.2008 12:27

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Это какой sparc? 32-х битный или 64-х битный? (я в спарках не силен)
А, блин... торможу... написано же в сабже - sparc32

Вообще по идее должно быть выровнено. Порыл ядро, ничего не нарыл... но точно знаю что memcpy для sparc свое!

Попробуй ради эксперимента взять ядро посвежее. 2.6.27 вышло сегодня

PS: Это что за народное творчество блин???

arch/sparc/kernel/traps.c:


void die_if_kernel(char *str, struct pt_regs *regs)

{

        static int die_counter;

        int count = 0;



        /* Amuse the user. */

        printk(

"              \\|/ ____ \\|/\n"

"              \"@'/ ,. \\`@\"\n"

"              /_| \\__/ |_\\\n"

"                 \\__U_/\n");

[ Редактирование Пятница 10.10.2008 12:50 ]

Андрей Валяев

Наверх

Dron

Пятница 10.10.2008 12:43

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Вот еще что подумал... i_size действительно может быть не выровненным.

загляни в include/linux/fs.h там описана эта структура. i_size стоит не слишком в начале, и есть всякие подозрительные типы, которые могут иметь на разных платформах разные размеры.

Можно попробовать просто переставить его в начало. по идее это не должно ничего сломать. но хрен знает.

В противном случае можно попробовать добавить выравнивающее поле для спарки. типа того:




#ifdef CONFIG_SPARC

        uint32_t aligner;

#endif

        loff_t i_size;

А для начала просто убедиться, что offsetof(struct inode, i_size) действительно не делится на 64

Андрей Валяев

Наверх

vv40in

Пятница 10.10.2008 13:47

ID пользователя #1076

Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62

(см.в первом письме) куда бы ты не поставил поле - в ядре много алокаторов и они моут выделить стркутуру с каким-то другим выравниванием(?) как им (выравниванием алокаторов) управлять? или эту структуру можно создать в стеке. тогда какое будет выравнивание?

Наверх

Dron

Пятница 10.10.2008 13:54

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Я так полагаю что сам inode должен быть выровнен нормально.
Следовательно аллокаторы вовсе не при чем. а виноваты именно типы uid_t, guid_t, dev_t и еще че-то, что там стоит перед i_size?

хотя не исключено что и аллокаторы выравнивают только на 8, но в этом тоже легко убедиться проверив какой нибудь из указателей на inode.

[ Редактирование Пятница 10.10.2008 14:09 ]

Андрей Валяев

Наверх

vv40in

Пятница 10.10.2008 14:00

ID пользователя #1076

Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62

в том-то и дело, что алокатор выделил структуру выравняв ее по 4 байтам (не на

Наверх

vv40in

Пятница 10.10.2008 14:04

ID пользователя #1076

Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62

щас добавил
__attribute__ ((aligned (8)));
посмотрю что получится

Наверх

Dron

Пятница 10.10.2008 14:08

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Во, я нашел

ARCH_KMALLOC_MINALIGN

для Sparc она никак не определена, и поэтому инитится по дефолту в mm/slab.c
Ее можно наверное прописать в arch/sparc/include/asm/page.h в нужное значение.

Для верности можно так же проинитить и ARCH_SLAB_MINALIGN.

Естественно инитить все нужно в 8.

PS: Какая отсталая архитектура что у них даже include/asm хранится почему-то не в include а в arch.

[ Редактирование Пятница 10.10.2008 14:09 ]

Андрей Валяев

Наверх

Переход на страницу [1] 2 3
Перейти: Наверх