jcmvbkbc

Как происходит доступ к эл. массива на уровне ядра?

Так же как и на уровне приложения -- через трансляцию виртуального адреса в физический.

Например массив Int* arr = new int[1024*1024*1024] он как храниться?

Если мы для определённости возьмём linux, то у ядра есть несколько разных способов выделения памяти, в зависимости от того, для чего эта память выделяется. Есть наиболее простой и стандартный kmalloc который выделяет память непрерывную как виртуально так и физически. Обычно этим механизмом нельзя выделить большой непрерывный кусок. Есть vmalloc, который выделяет непрерывную виртуально, но возможно прерывную физически память. Есть get_free_pages который выделяет непрерывные страницы физической памяти, возможно, не отображаемые ни в какие виртуальные адреса. Есть Contiguous Memory Allocator который при старте системы резервирует кусок непрерывной физической памяти и может аллоцировать оттуда куски по запросу.
Важный момент состоит в том, что аллокации делаемые ядром linux через упомянутые интерфейсы всегда обеспечиваются физической памятью, у памяти ядра нет пейджинга.

А физическая, для массива то же? Ведь, так будет доступ намного быстрее?

Почему быстрее? С точки зрения процессора всё равно будет трансляция виртуального адреса в физический, если повезёт -- попадание в TLB, если не повезёт -- ходить по каталогам и таблицам страниц в памяти.

получается эмулятор каждый адрес вычислять что ли?

Простой эмулятор -- да, наверно. Умный эмулятор может кешировать эту информацию, например именно это свойство даёт QEMU большую часть его Q.

Для процессора x86 с word 32bit. Как будут выполняться fetch?
Хочу ответ в таком формате.

Что мешает взять спецификацию на процессор и почитать, например, раздел 5.3.6?

почему процессор обращается 2 раза к невыравненным данным?

Если посмотреть на схему i386 на первой же странице документа по ссылке выше, то можно увидеть, что шина адреса процессора имеет линии A2 - A31. Линий A0 и A1 тупо вообще нет, физически.

Please specify the compatibility level in debian/compat
or via Build-Depends: debhelper-compat (= X)

Искал в тексте упоминания debhelper-compat, но не нашел.

Насколько я понял этот документ, рекомендуется указывать зависимость от debhelper-compat вместо зависимости от debhelper. Т.е. надо самому написать

Build-Depends: debhelper-compat (= 13), texi2html, texinfo

Часто вижу в коде на C++ и C#, что для счётчиков … используют int, а не uint/unsigned int.
Почему праграмисты делают это?

Я слышал следующую теорию, почему это имеет смысл в С++: потому что значение знакового типа в корректно написанном коде не переполняется. (А если таки случилось переполнение, то это UB и всё уже не важно). Поэтому если счётчик имеет знаковый тип и с ним на каждой итерации происходит, например, инкремент, то значение счётчика только увеличивается. Это, в свою очередь, даёт дополнительные возможности для оптимизации. Беззнаковый счётчик инкрементируемый на каждой итерации может внезапно обнулиться, это может быть легальным поведением программы на которое рассчитывает программист.

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

Как передать двумерный массив функции?

https://qna.habr.com/answer?answer_id=513953#answe...

"$str2$str1"

'/usr/bin/python3 /opt/uccx-stats/uccx_parse.py /opt/uccx-stats/_uccx_csqstats.txt "FCCPS-CSQ - loggedinagents"'

подскажите, как это победить

убрать кавычки там где они не нужны, добавить кавычки там, где они нужны:

#!/bin/bash
set -x
#Запуск скрипта в формате ./csqstats CSQ_name  param
str1="$1 - $2"
str2="/usr/bin/python3 /opt/uccx-stats/uccx_parse.py /opt/uccx-stats/_uccx_csqstats.txt"
$str2 "$str1"

С минимальными изменениями можно сделать вот такой рабочий вариант:

#!/bin/bash
function generateArgs(){
 echo --arg1=$somevar1 \"--arg2=$somevar2 and spaces\" ... --arg1337=$somevar1337
}
eval "args=($(generateArgs))"
exec java "${args[@]}"

Т.е. каждый отдельный аргумент в котором могут быть пробелы вывести с кавычками и собрать их в массив. Элементы массива в подстановке "${args[@]}" передаются поотдельности и пробелы внутри них обрабатываются правильно.

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

с чем могут возникнуть проблемы

Можно начать отсюда.
Из моего опыта, самое часто всплывающее отличие glibc от других libc -- поддержка версионирования символов.

В чем проблема? Что я делаю не так?

Я подозреваю, что не нужно делать regs.rip -= 1 ;, потому что процесс не может "выполнить" точку останова.
Ну и для надёжности, я бы убедился, что в памяти куда пишется 0xcc действительно до этого было 0x55.

Могу ли я не используя vec4, задать выравнивание элементам массива?

Не используя для элементов массива другой тип -- нет, не можешь. Не обязательно испольовать для этого vec4, можно завести какой-нибудь другой тип, породив его от vec3 и задав нужное выравнивание.

Можно ли как-то защититься от этого; есть ли для этого какие-то специальные протоколы?

Для этого бывают key signing party, когда сопоставление ключа и владельца происходит очно.
Либо PKI, если не стрёмно отдать эту функцию на аутсорс.

А как передать-то 32 битное значение в команде в 32 бит?
Логично что после команды значение(или адрес). Но тогда же получается какое-то нарушение логики.

В RISC-процессорах -- никак. Они либо имеют команду загрузки 32-битного значения (литерала) из памяти относительно PC или специально выделенного регистра (например ARM: LDR r [pc, #offset_to_literal_pool], XTENSA: l32r at, label), при этом в команде кодируется смещение адреса литерала относительно PC. Либо загружают значения по частям, двумя или более командами (например MIPS загружает 16-битные части двумя разными инструкциями: lui rt, high16 ; ori rt, low16, XTENSA загружает 16-битные части двумя одинаковыми инструкциями: CONST16 at, high16 ; CONST16 at, low16, RISC-V загружает 20 и 12-битные части: auipc rd, symbol[31:12] ;addi rd, rd, symbol[11:0]).
Хотя в принципе тот же RISC-V имеет нефиксированную длину команд, так, что какой-нибудь разработчик может завести, скажем, 6-байтовую команду загрузки 32-битного непосредственного значения в регистр, однако, насколько мне известно, никто этого не делает.

Вот описание

Это описание не компилируется в силу его неполноты. Приведи полный, собирающийся текст.