jcmvbkbc

Но в режиме отладки всё, как я уже писал выше, работает.

Да не, это только видимость. Смотри:

$ gcc -std=c99 -O2 -g3 -fsanitize=address main.c acp.c md5.c -o main
$ ./main
Base64('Hello') = "SGVsbG8="
MD5('Hello') = "8b1a9953c4611296a827abf8c47804d7"
=================================================================
==1045705==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000071 at pc 0x7fb0d46486f8 bp 0x7ffd0affb580 sp 0x7ffd0affad30
WRITE of size 33 at 0x604000000071 thread T0
    #0 0x7fb0d46486f7 in __interceptor_strcat ../../../../src/libsanitizer/asan/asan_interceptors.cpp:377
    #1 0x564b2388c0de in prepareKeys /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:263
    #2 0x564b2388cac4 in acraw /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:319
    #3 0x564b2388d8c2 in acraws /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:401
    #4 0x564b2388d8c2 in acraws_basic /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/acp.c:409
    #5 0x564b2388a62e in testSimpleEncryption /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main.c:20
    #6 0x564b2388a368 in main /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main.c:111
    #7 0x7fb0d44461c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #8 0x7fb0d4446284 in __libc_start_main_impl ../csu/libc-start.c:360
    #9 0x564b2388a440 in _start (/home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/main+0x3440)

0x604000000071 is located 0 bytes to the right of 33-byte region [0x604000000050,0x604000000071)
allocated by thread T0 here:
    #0 0x7fb0d46b89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x564b2388fee7 in md5StringHash /home/jcmvbkbc/tmp/toster/1331202/alphacrypt2/md5.c:227

g++  ...   src/core_cm3.c src/system_stm32f10x.c -o build/main

src/core_cm3.c: Assembler messages:
src/core_cm3.c:447: Error: no such instruction: `mrs %eax,psp'

На какой системе ты выполняешь сборку, на x86? Тогда чтобы получить код для arm тебе нужен не g++, а какой-нибудь arm-linux-gnueabi-g++.

Зачем он для такой строчки на 69, 70ой строчке добавляет к j такую странную константу.

В конечном коде выглядит действительно загадочно. Если вызывать компилятор с ключом -fdump-tree-all (фиг знает, как сделать это на godbolt.org, я проверял локально), то уже в самом первом дампе можно увидеть, что if (arr[j - 1] > arr[j]) превращается в это:

if (*(arr + ((sizetype) j + 1073741823) * 4) > *(arr + (sizetype) ((unsigned int) j * 4)))

1073741823 -- это 0x3fffffff, 30 единичных бит, т.е. 30-битная -1. Дальше j + 1073741823 превратилось в

add     r3, r3, #1073741824
subs    r3, r3, #1

т.е. в j + 1073741824 - 1. После умножения на 4 старшие два бита j теряются, но в чём смысл использования 30-битной -1 вместо 32-битной -- мне непонятно.
Поскольку константа появляется ещё до начала архитектурно-зависимых преобразований, она фигурирует в выводе для всех 32-битных архитектур поддерживаемых gcc. Интересно, что это началось между gcc-4.6 и gcc-5, до этого в этом месте генерировался просто sub r3, r3, #1. Ещё интересно, что даже с -O2 эта константа остаётся в сгенерированном коде, а исчезает только с -Os. Выглядит как регрессия.

При сборке проекта, возникает ошибка ненахождения метода.

Убедись, что -lboost указан после -lcpprest в команде линковки.

на сегодня уже хватит программирования?

на сегодня уже хватит программирования. Речь о размере объекта (в байтах), а каждый элемент массива int наверняка занимает хотя бы 4 байта.

Как вызвать из C++ программы функции на ассемблере?

extern "C" void number1();
…
int main()
{
number1();
}

Именно так.

а вот остальные не могу

Так а просто -static? Это не "встроит dll в exe" а слинкует со статической версией всех библиотек.

Смысл его прост: отменить действие макроса в определенной части кода, а по ее истечении восстановить этот макрос.

Таким образом этого сделать нельзя. Потому что в месте где написано #define temp func значение макроса func не подставляется. В temp попадает буквально слово func. После #undef func содержимое макроса func будет потеряно. Это поведение предписано стандартом, мне неизветсны опции компилятора, которыми его можно было бы изменить. См. eelis.net/c++draft/cpp.replace#10 и eelis.net/c++draft/cpp.rescan

Но если внести ещё один уровень косвенности, то можно сделать чтобы это работало. Например:

#define foo bar
#define func foo
...
#undef func
...
#define func foo

Логичнее было бы воспользоваться опцией -mstackrealign чтобы выравнивать стек на входе в функцию.

Как в gcc сохранять объектные файлы

Опция -o -- путь к результату, препроцессирования/компиляции/линковки. Научи свой Makefile подставлять правильный путь в эту опцию.
Ты скажешь "а у меня 100500 исходных файлов компилируется разом". Ответ -- а не надо так делать. Компилятор всё равно вызывается каждый раз новый. Напиши правило компилирующее один файл в нужный каталог -- и выполни его по разу для каждого исходника. Например так:

NAME = calc

SRC = main.c \
  parser.c \
  ft_lib/ft_atoi.c \
  ft_lib/ft_putchar.c \
  ft_lib/ft_putnbr.c

BUILDDIR=build
OBJ = $(addprefix $(BUILDDIR)/,$(subst /,_,$(patsubst %.c,%.o,$(SRC))))

FLAGS = #-Wall -Wextra -Werror

all: $(NAME)

$(NAME): $(OBJ)
  gcc $(OBJ) -o $(NAME)

define CC_RULE =
$(BUILDDIR)/$(subst /,_,$(patsubst %c,%o,$(SOURCE))): $(SOURCE)
  gcc $(FLAGS) -c $< -o $@
endef

$(foreach SOURCE,$(SRC),$(eval $(call CC_RULE,$(SOURCE))))

clean:
  rm -f $(OBJ)

fclean:
  rm -f $(NAME)

re: fclean all

Смотри: я сделал список объектников из $(SRC), написал генератор CC_RULE, который для любого исходника генерирует правило компиляции его в объектник под $(BUILDDIR) и вызвал его для всех исходников в $(SRC).

Это забавное развлечение, но гораздо практичнее воспользоваться существующей системой сборки: autotools/CMake/...

asm (
    "mov a, %eax \n\t"
    "mov b, %ebx \n\t"
    "add %eax, %ebx \n\t"
    "mov %ebx, c \n\t"
  );

Так в gcc не работает. Должно быть например так:

asm (
    "mov %[a], %%eax \n\t"
    "mov %[b], %%ebx \n\t"
    "add %%eax, %%ebx \n\t"
    "mov %ebx, %[c] \n\t"
    : [c] "=rm" (c)
    : [a] "rm" (a), [b] "rm" (b)
    : "eax", "ebx", "cc"
  );

Что это всё значит можно почитать тут.

Компилирую, а тут фигня происходит:

Ошибка говорит о том, что код попытался обратиться к глобальному символу a, но такого символа нет. Потому что переменная a размещена на стеке и символьного имени у неё и правда нет. Если бы она (вместе с b и c) была глобальной, всё равно была бы ошибка (по крайней мере при компиляции под 64 бита), но другая.

Для gcc и его libstdc++ есть таблица соответствия версии компилятора и версии символов из его библиотеки, а так же описание правил, по которым версии изменяются и вообще всей идеи версионирования ABI: https://gcc.gnu.org/onlinedocs/libstdc++/manual/ab...