Как мога да направя листинг на всички променливи на един ELF файл ?
Успях да го докарам до прост листинг с адресите на променливите, но ми трябват
още типовете и размера в байтове. Всъщност размера ми го дава нулев за
всички променливи от листинга (това за dsPICxxx)

По принцип искам да мога да се закача за работещо приложение на произволен микроконтролер
(Microchip, AVR, ARM) и от ПК да му давам кои променливи да ми изпраща по произволен интерфейс
(Eth, USB, UART, SPI, I2C, CAN и т.н.) Вътре в микроконтролера си има debug код, който чака ПК да
му изпрати списък с адрес и размер, след което започва да ги чете и изпраща на определено време
към ПК. Един вид trace, само че софтуерен.

От страната на ПК (Windows/Linux/Mac) програмата прави от ELF файла списък с всички променливи,
техния тип и размер (затова ми трябва листинга на ELF файла), а юзера си избира кои променливи да
следи или да логва, след което програмата праща списъка на микроконтролера (във формат:
адрес-размер) и започва да слухти за данните.

Microchip имаха подобен сорт "trace", но от страната на ПК е отвратителна работа, така и не можах
да му свикна. Та искам да си направя нещо такова, което да мога когато си пожелая да го закача
към работещо приложение (стига вътре да е програмиран trace кода и да знам кой му е интерфейса)

адресите ги имаш в MAP файла
проект\dist\default\production
или линкер, диагностика --cref --print-map > MyMapFile.txt

ама дължината им.......

PS: разбрах те ама късно

То и аз малко го обясних по-сложния начин , Microchip му казват RTDM(Real Time Data Monitor) , но
не ми харесва User интерфейса, освен това е лимитирано само до UART, и само до техните професори.
Пък ако мога да извадя от ELF файла имената на променливите, техния тип и размер тогава става
универсално помагало за всякакви професори.

pic30-objdump -D -EL -f -h -omf=elf v18_5.X.production.elf
ми дава следното:



Като колоната Size е нула за абсолютно всички променливи. Сега не знам дали това
е типично за objdump за целия GNU binary utilities или Microchip-ския е усран. Пробвах
на C30 и XC16 с различни версии, няма разлика.

Няма ли да бави приложението в пика, а и все пак повечето дебъгерски операции са хардуерни и не е предвидено софтуерни breakpoints на 24/30/33 серията
мисля че е 32-ките има разширен дебъг, но не съм сигурен...

Преди време правих подробен "клиентски" дебъг за GSM с PIC24:

един u16 с дефинирани битове като нива за разделно разрешаване - какво да принтва на дебъг кома
а в приложенито бях натурял
LOG(LEVEL_SYS, "изречение %d %d,......", params....)
LOG(LEVEL_GSM, "изречение %d %d,......", params....)

ако LEVEL_XXX е разрешен - принтва само тази периферия

elf-формата все пак не е краен .bin за наливане в микроконтролер. изисква лоудер, да му намести секциите в паметта, дори и да е чисто статично линкнат.

от друга страна, информацията, която можеш да извлечеш ще касае само статични глобални променливи. няма да са ясни локални променливи (във функции), параметри на функции, променливи в стековия фрейм, да не говорим за регистрови променливи. в този смисъл, упражнението дори не е половинчато, по-добре се насочи към смислено ползване на вградения тейс модул.

на нормално gcc с objdump -t се вижда големината на променливите, нямам идея на мокрочипското какво са орязали.
виж какво ти връща readelf -s

първата колонка 'value' е някакъв виртуален номер, не е адрес.
и променливите са винаги от тип 'object'

на GSM модулите ( повечето ) като се конекнеш по сътветния начин (UART или TCP) бълват ВСИЧКО, а с ELF(мап) само филтрират

PS: .... може да филтрират и при конекция ?!

Пълно щастие няма. За глобалните променливи, използвайки стандартните инструменти от GNU bin utilities
мога да получа адрес и размер. При Microchip се оказа, че нещо са осрали, затова размера им е винаги 0
(каквито и опции да задавам на objdump и readelf)

Вградения трейс, хубаво нещо, но неприложимо в много ситуации. На мен ми трябва просто решение, което да работи
на всякави контролери, с рейс, без тРейс, както дойде. RTDM на Microchip съм го изполвал и работи добре, но
User интерфейса ми е трън в очите. Същевременно не искам да копам в структурата на ELF файла, щото утре ще променят
нещо и трябва да копам наново. Затова си мислех, ако може чрез съществуващите функции на GNU Bin utilities да извличам
три неща: адрес, размер и тип. Да, адреса (втората колонка, Value) може и да не е реалния в паметта,
но все пак може сравнително лесно да са намери.. Ако обаче променливите са винаги от тип 'object', то тогава начинанието си губи смисъла, т.е.
ще трябва да се чете и анализира ELF файла. Някой да има подходящо четиво за ELF структурата, ако може да е
за ниво на полу-идиоти

ми четива за elf - колкото искаш в нета. ако се почустваш пълен идиот, прочети документа до половината, и така ще стане за полу-идиоти
проблема е, че за всяка архитектура си има национални особености - 32/64, ABI, EABI, no-EABI и каквото там са натворили в маркото и основното gnu. в този смисъл ми се вижда малко невъзможна задачката ти, особено ако намесиш малки пикльовци, AVR и подобни.

типовете на променливите ги няма в символната таблица (там са object, function и подобни). можеш да ги извадиш от дебъг секцията, но трябва да я има -> да можеш да вкараш elf-а в gdb и да видиш променливите (ptype име_на_променлива).
виж на твоя мокрочипски elf дали работи
readelf --debug-dump=info

Как и с какво правите от elf, Apk за Андроид?