информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft предупредила о двух незакрытых... 
 Перевод Firefox на DNS over HTTPS 
 Microsoft закрыла серьёзную уязвимость,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Unix] Все указатели менять не надо 01.07.03 18:37  Число просмотров: 865
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Сама софтина предполагает работу с файлом типа битмапов и
> прочей ерунды. Т.е. я так понимаю на ППЦ другая организация
> памяти:
>
> x = 0x10203040
> PPC: 0x10203040
> X86: 0x40302010

Как оно хранится в памяти тебя не касается. Смысл C-шных выражений не поменялся и хорошо. Единственная проблема - при чтении файла читать в нужном формате. В частности для битмэпов это касается только заголовков, так все остальные данные - байты, а для них это несущественно.

> а файло в бинарном виде храниться вот так:
>
> PPC: 20104030
> X86: 40302010
>
> так?
Вроде нет. Зачем на ppc менять порядок байтов на middle-endian? Если нужно просто сохранить с последующим чтением на той же платформе, то самый правильный способ - просто сдампить память.

> Как с помощью какихнть директив сделать кросс-платформенный
> код. А то как-то невесело переписывать каждый указатель в
> проге :(
Опций никаких. Нужно чтоб код с самого начала писался портабельным. Иначе его придется портировать вручную. Правда каждый указатель переписывать не придется. Все что не уйдет с данной платформы (все операции в регистрах и памяти) менять не обязательно. Но нужно очень внимательно следить за тем, что читается/пишется в файлы. Если прога на C++, можно ввести целый тип для little-endian (переопределить для него все арифметические операции, операции присвоения, преобразования и т.д.) и переписать структуру заголовка битмапы с использованием данного типа.

Удачную реализацию встроенной кроссплатформенности можешь посмотреть например в исходниках upx-а.
<programming>
[Unix] PowerPC & big-endian porting проблемы... 01.07.03 18:12  
Автор: NeuronViking Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Всем привет!

Такая проблема: есть сырцы одной софтины для Intel архитектуры. Нужно поротировать их на платформу PowerPC. Каким образом это можно сделать с наименьшими усилиями и быстро? Какие есть грабли при переходе от little-endian на big-endian? На что стоит обратить особое внимание? Ну и т.д. и т.п. Никогда еще не общался с ППЦ платформой... посоветуйте что делать и где можно почитать. В инете не очень много инфы нашел.
Сама софтина предполагает работу с файлом типа битмапов и прочей ерунды. Т.е. я так понимаю на ППЦ другая организация памяти:

x = 0x10203040
PPC: 0x10203040
X86: 0x40302010

а файло в бинарном виде храниться вот так:

PPC: 20104030
X86: 40302010

так?
Как с помощью какихнть директив сделать кросс-платформенный код. А то как-то невесело переписывать каждый указатель в проге :(
[Unix] Все указатели менять не надо 01.07.03 18:37  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Сама софтина предполагает работу с файлом типа битмапов и
> прочей ерунды. Т.е. я так понимаю на ППЦ другая организация
> памяти:
>
> x = 0x10203040
> PPC: 0x10203040
> X86: 0x40302010

Как оно хранится в памяти тебя не касается. Смысл C-шных выражений не поменялся и хорошо. Единственная проблема - при чтении файла читать в нужном формате. В частности для битмэпов это касается только заголовков, так все остальные данные - байты, а для них это несущественно.

> а файло в бинарном виде храниться вот так:
>
> PPC: 20104030
> X86: 40302010
>
> так?
Вроде нет. Зачем на ppc менять порядок байтов на middle-endian? Если нужно просто сохранить с последующим чтением на той же платформе, то самый правильный способ - просто сдампить память.

> Как с помощью какихнть директив сделать кросс-платформенный
> код. А то как-то невесело переписывать каждый указатель в
> проге :(
Опций никаких. Нужно чтоб код с самого начала писался портабельным. Иначе его придется портировать вручную. Правда каждый указатель переписывать не придется. Все что не уйдет с данной платформы (все операции в регистрах и памяти) менять не обязательно. Но нужно очень внимательно следить за тем, что читается/пишется в файлы. Если прога на C++, можно ввести целый тип для little-endian (переопределить для него все арифметические операции, операции присвоения, преобразования и т.д.) и переписать структуру заголовка битмапы с использованием данного типа.

Удачную реализацию встроенной кроссплатформенности можешь посмотреть например в исходниках upx-а.
[Unix] PowerPC & big-endian porting проблемы... 01.07.03 18:21  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
Вопрос - а ты уже пытался просто перекомпилить эти сорцы на PowerPC? Я так и не понял из твоего поста - что за проблемы-то?
[Unix] Дык собс-но... 01.07.03 19:32  
Автор: NeuronViking Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Вопрос - а ты уже пытался просто перекомпилить эти сорцы на
> PowerPC? Я так и не понял из твоего поста - что за
> проблемы-то?

собираюсь перекомпилить.. завтра с утра и займусь этим. Просто хочу узнать какие где грабли расставлены чтобы не наступить на них. Вот.
Сырцы на чистом С, никакого асма или С++ нет.

Т.е. я так понял из предыдущего поста что за саму софтину не стоит переживать - GCC компилер сделает все как надо на ППЦ платформе? Единственное о чем стоит позаботится так это о внешних данных, т.е. например порядке чтения данных из файлов? Можно апроксимировать это на конкретный пример? Вот к примеру открывается картинка таким образом:

fd = open(BmpFileName, O_RDWR);
rc = fstat(fd,&fd_info);
fd_addr = (BYTE*)mmap(NULL, fd_info.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
memcpy(&bfh, fd_addr, sizeof(BITMAPFILEHEADER));
memcpy(&bih, fd_addr+sizeof(BITMAPFILEHEADER), sizeof(BITMAPINFOHEADER));

структуры BITMAPFILEHEADER и BITMAPINFOHEADER объявлены в хидере внутри pragma pack(1) ...

здесь есть глюк или нет? С полями структур работать точно так же или надо менять местами слова в DWORDе и байты в WORDе?
Потом идет работа непосредственно с байтами через указатель fd_addr...

И еще, что дает опция GCC -mlittle-endian вместе с -mpowerpc?
[Unix] Дык собс-но... 02.07.03 15:43  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Т.е. я так понял из предыдущего поста что за саму софтину
> не стоит переживать - GCC компилер сделает все как надо на
> ППЦ платформе? Единственное о чем стоит позаботится так это
> о внешних данных, т.е. например порядке чтения данных из
> файлов? Можно апроксимировать это на конкретный пример? Вот
> к примеру открывается картинка таким образом:
>
> fd = open(BmpFileName, O_RDWR);
> rc = fstat(fd,&fd_info);
> fd_addr = (BYTE*)mmap(NULL, fd_info.st_size, PROT_READ,
> MAP_PRIVATE, fd, 0);
> memcpy(&bfh, fd_addr, sizeof(BITMAPFILEHEADER));
> memcpy(&bih, fd_addr+sizeof(BITMAPFILEHEADER),
> sizeof(BITMAPINFOHEADER));
>
> структуры BITMAPFILEHEADER и BITMAPINFOHEADER объявлены в
> хидере внутри pragma pack(1) ...
Лучше всего или переписать BITMATHEADER используя переопределенные типы. Например вместо DWORD написать LE_DWORD (то бишь little-endian) и для него написать class LE_DWORD {...}, в котором переопределить все операции, так чтобы компилятор автоматически работал с ним как с LE. Тогда тебе вообще больше ничего менять не придется. Если C++ не подходит, придется искать все обращения к WORD-ам и DWORD-ам (к CHAR-ам не надо - тут все нормально) этой структуры и обрабатывать их - не самое приятное занятие.

> здесь есть глюк или нет? С полями структур работать точно
> так же или надо менять местами слова в DWORDе и байты в
> WORDе?
Надо менять. Так как в память они попадут в little-endian формате (в точности как в файле), а проц будет считать их big-endian-ами.

> Потом идет работа непосредственно с байтами через указатель
> fd_addr...
>
> И еще, что дает опция GCC -mlittle-endian вместе с
> -mpowerpc?
Это значит, что gcc кроссплатформенный. То бишь на любой платформе ты можешь скомпилить код для любой другой из поддерживаемых. По умолчанию всегда стоит родная платформа. То бишь на i386 ты конечно сможешь собрать прогу для ppc, но работать она точно не будет :-) А на самом ppc эти ключи как бы и по умолчанию :-)

ЗЫ: А разве в ppc нет флага какого-то, который переводит проц в little-endian? Не помню точно, но кажется такое было. Тогда тебе просто придется дописать пролог для проги, в котором выставить флаг и все.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach