LINUX.ORG.RU

Как проект GNU работает с кодами машинных команд?

 , ,


0

3

В 1993-м году было так:

The GNU assembler provides assembly and disassembly for many targets, but different techniques are applied ad hoc to support different architectures [Elsner et al. 1993]. For example, Pentium instructions are recognized by hand-written C code, but MIPS instructions are recognized by selecting a mask and a sample from a table, applying the mask to the word in question, then comparing the result against the sample. On both targets, operands are recognized by short programs written for abstract machines, but a different abstract machine is used for each target. Another set of abstract machines is used to encode instructions during assembly. The implementations of the abstract machines contain magic numbers and hand-written bit operations. The programs interpreted by the abstract machines are represented as strings, and they appear to have been written by hand.

Что поменялось за 31 год?

★★★

Последнее исправление: hobbit (всего исправлений: 1)

Что поменялось за 31 год?

С 2021 по 2024 — не очень многое

За остальные годы смотри ченджлоги по годам там же: https://sourceware.org/git/?p=binutils-gdb.git;a=tree

как проект GNU работает с кодами машинных команд?

Так: https://sourceware.org/git/?p=binutils-gdb.git;a=tree

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Нужен специалист по ChatGPT, который выполнит операцию «обобщить и предоставить сводку» с помощью какой-нибудь ИИ-утилиты.

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

сейчас специалистов по чатжопотэ сейчас больше чем экономических спецов в 00-е… :)
готовь денюжку и точное тех.задание на поиск

а что там менять ?? за 31 год формат и параметры команды процессора не менялись, это вам не медиа-дезигн.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

REX-байт (REX prefix) был введен в архитектуру x86-64, которая была представлена в процессоре AMD Opteron, выпущенном в 2003 году. Это был первый процессор, который поддерживал 64-битные расширения x86.

Intel позже лицензировала эту технологию и выпустила свои собственные процессоры с поддержкой x86-64 (начали работу в 1999 году), начиная с процессора Core 2, выпущенного в 2006 году.

Таким образом, технологии 1993-го года не могут учитывать новшества 1999-2006 годов, и они были как-то доработаны.

«не менялись»

Вы, очевидно, ошибаетесь. Не надо так.

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

появилась новая команда в разбираемом тексте.
для образца взялась функция/регексп/лямбда/прочая_фигня по парсингу подобной фнкции - методом копи-паст сделали копию.
копия допилилась напильником под новую функцию.
….
профит.

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

вот если б дизассемблер сразу генерил из бинаря x86-64 готовый и какчественный ООП с++ код (а лутше сразу js), а не ентую всю низкоуровневую никому непонятную хрень, которую еще надо додумывать кучу времени, вот енто был бы номер !!

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)
Ответ на: комментарий от Shushundr

Ассемблер работает и поддерживает современные процы. Сами алгоритмы менялись мало. Что тебя ещё интересует и зачем тебе это нужно? Ассемблер это не какая-то сложная штука чтобы всякие изыски на нём оттачивать, при желании пишется за пару дней. Но он нужен и поэтому вот он есть в binutils.

firkax ★★★★★
()
Ответ на: комментарий от Shushundr

технологии 1993-го года не могут учитывать новшества 1999-2006 годов, и они были как-то доработаны.

Подваливанием новых кучек флажков и соответствующих костыльков.

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/i386-tbl.h;hb=HEAD

vM ★★
()
Ответ на: комментарий от vM

Там первая строчка в файле

This file is automatically generated by i386-gen.

Это означает, что неважно, что там в коде, нужно смотреть на абстрации более высокого уровня, из которых эти флажки были нагенерированы.

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

И как они затем используются, будучи заранее нагенерёнными.

vM ★★
()
Ответ на: комментарий от pfg

за 31 год формат и параметры команды процессора не менялись

Ну это, батенька, смотря какого процессора. Даже у x86 появилась amd64 (2000 год) и ещё дофига чего по мелочи. А уж за его пределами… Актуальность MIPS, по-видимому, сильно упала, зато резко возросла актуальность различных ARMов, а теперь ещё и RISC-V…

Мне вот например вообще интересно, как тот же gas со всем этим хоть как-то управляется, или тут вообще надо смотреть на другие ассемблеры.

hobbit ★★★★★
()
Ответ на: комментарий от pfg

а что там менять ??

Сам факт того, что появляются новые проекты, такие как
LLVM MC Project
говорит о том, что всё течёт всё меняется

Shushundr ★★★
() автор топика
Ответ на: комментарий от vM

[Capstone] паразитирует на имеющейся базе LL(VM/DB etc.)

Хотелось бы кровавых подробностей, а то они пишут, что:

  1. we reimplemented all the dependent layers of LLVM to remove unneeded code

  2. LLVM is implemented in C++, but Capstone is implemented in pure C, making it much easier to be adopted

  3. Capstone can handle quite a lot of tricky X86 undocumented instructions that are not supported by LLVM.

Где, например, описан формат .td, или как вообще это всё работает?

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
$ i386-gen
bash: i386-gen: command not found
$ equery files binutils | grep "^/usr/x86_64-pc-linux-gnu/binutils-bin/"
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/addr2line
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/ar
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/as
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/c++filt
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/elfedit
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/gprof
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/ld
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/ld.bfd
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/nm
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/objcopy
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/objdump
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/ranlib
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/readelf
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/size
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/strings
/usr/x86_64-pc-linux-gnu/binutils-bin/2.40/strip
sys-libs/binutils-libs
--  sys-libs/zlib
--  sys-devel/binutils-config
--  sys-devel/gettext
--  dev-util/dejagnu
--  app-portage/elt-patches

Вот исходник:
https://sourceware.org/git/?p=binutils.git;a=blob;f=opcodes/i386-gen.c;hb=HEAD
но куда он устанавливается?

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 4)
Ответ на: комментарий от vM

использует более опытную libopcode(s)

«libopcodes is a pain to use»
https://stackoverflow.com/questions/9132006/how-to-get-instruction-information-from-libopcodes
«it is under-documented»

как собирать

Берём доку на binutils:
https://sourceware.org/binutils/docs-2.42/binutils.html
и в ней нет слова libopcodes!
На wiki тоже ничего нет:
https://sourceware.org/binutils/wiki/HomePage?highlight=%28libopcodes%29

Примеры:

  1. https://www.toothycat.net/wiki/wiki.pl?Binutils/libopcodes
  2. https://blog.yossarian.net/2019/05/18/Basic-disassembly-with-libopcodes

Но это всё не объяснение того, как это всё работает.

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 6)
Ответ на: комментарий от firkax

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

И получится неюзабельная незадокументированная фигня, которая умрёт как только от неё откажется её первый автор. Проект это вам не хухры-мухры, это море документации и вспомогательной работы (и в два дня это никак не уложится).

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

И получится неюзабельная незадокументированная фигня

Не все такие тугодумы как ты. Ассемблер весьма тривиален и там почти негде запутаться нормальным людям.

firkax ★★★★★
()
Ответ на: комментарий от Shushundr

Вот для начала изучи ассемблер (не асм-компиляторы а сам язык), поиспользуй его для написания софта, потом для реверса бинарников дизассемблером, и потом уже лезь в дискуссии о работе асм-компиляторов. А сейчас ты просто неграмотный флудер, который нашёл себе очередную тему для графомании, это выглядит убого.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Там даже разработчики процессоров запутались.

#include <stdio.h>

asm(".global test\n"
    "test:\n"
    /* Clear the carry flag so that the following "jc" does not jump. */
    "clc\n"
    /* "66 0f 82" is the encoding for "data16 jc".  "jc" is also known
       as "jb".  On x86-32, this takes a 2-byte operand, so it
       executes "jmp size2".  On x86-64, this takes a 4-byte operand,
       so it executes "jmp size4". */
    ".ascii \"\\x66\\x0f\\x82\\x00\\x00\"\n"
    /* We assume that this jump is encoded as a 2-byte instruction. */
    "jmp size2\n"
    "jmp size4\n"
    "size2: jmp size_is_2\n"
    "size4: jmp size_is_4\n"
    );
void test(void);

void size_is_2() { printf("operand size is 2 bytes\n"); }
void size_is_4() { printf("operand size is 4 bytes\n"); }

int main() {
  test();
  return 0;
}
# На Intel
$ gcc test.c -o test -m64 && ./test
operand size is 4 bytes
# На AMD
$ gcc test.c -o test -m64 && ./test
operand size is 2 bytes

(https://sourceware.org/bugzilla/show_bug.cgi?id=13668)

monk ★★★★★
()
Ответ на: комментарий от monk

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от pfg

Гопота над этии работает. Чем машинные коды не промпт?

DumLemming ★★
()
Ответ на: комментарий от monk

У проекта GNU нет острой необходимости работать с такими полузарезервированными кодами машинных команд.

vM ★★
()
Ответ на: комментарий от hobbit

как тот же gas со всем этим хоть как-то управляется

так и управляется…

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/configure.ac#l355

https://github.com/riscvarchive/riscv-binutils-gdb/blob/riscv-binutils-2.38/opcodes/configure.ac#L263

 for arch in $selarchs
    do
	ad=`echo $arch | sed -e s/bfd_//g -e s/_arch//g`
	archdefs="$archdefs -DARCH_$ad"
	case "$arch" in
	bfd_aarch64_arch)	ta="$ta aarch64-asm.lo aarch64-dis.lo aarch64-opc.lo aarch64-asm-2.lo aarch64-dis-2.lo aarch64-opc-2.lo" ;;
	bfd_alpha_arch)		ta="$ta alpha-dis.lo alpha-opc.lo" ;;
	bfd_arc_arch)		ta="$ta arc-dis.lo arc-opc.lo arc-ext.lo" ;;
	bfd_arm_arch)		ta="$ta arm-dis.lo" ;;
	bfd_avr_arch)		ta="$ta avr-dis.lo" ;;
	bfd_bfin_arch)		ta="$ta bfin-dis.lo" ;;
	bfd_cr16_arch)		ta="$ta cr16-dis.lo cr16-opc.lo" ;;
	bfd_cris_arch)		ta="$ta cris-desc.lo cris-dis.lo cris-opc.lo cgen-bitset.lo" ;;
	bfd_crx_arch)		ta="$ta crx-dis.lo crx-opc.lo" ;;
	bfd_csky_arch)		ta="$ta csky-dis.lo" ;;
	bfd_d10v_arch)		ta="$ta d10v-dis.lo d10v-opc.lo" ;;
	bfd_d30v_arch)		ta="$ta d30v-dis.lo d30v-opc.lo" ;;
	bfd_dlx_arch)		ta="$ta dlx-dis.lo" ;;
	bfd_fr30_arch)		ta="$ta fr30-asm.lo fr30-desc.lo fr30-dis.lo fr30-ibld.lo fr30-opc.lo" using_cgen=yes ;;
	bfd_frv_arch)		ta="$ta frv-asm.lo frv-desc.lo frv-dis.lo frv-ibld.lo frv-opc.lo" using_cgen=yes ;;
	bfd_ft32_arch)		ta="$ta ft32-opc.lo ft32-dis.lo" ;;
	bfd_moxie_arch)		ta="$ta moxie-dis.lo moxie-opc.lo" ;;
	bfd_h8300_arch)		ta="$ta h8300-dis.lo" ;;
	bfd_hppa_arch)		ta="$ta hppa-dis.lo" ;;
	bfd_i386_arch|bfd_iamcu_arch|bfd_l1om_arch|bfd_k1om_arch)
				ta="$ta i386-dis.lo i386-opc.lo" ;;
	bfd_ia64_arch)		ta="$ta ia64-dis.lo ia64-opc.lo" ;;
	bfd_ip2k_arch)		ta="$ta ip2k-asm.lo ip2k-desc.lo ip2k-dis.lo ip2k-ibld.lo ip2k-opc.lo" using_cgen=yes ;;
	bfd_epiphany_arch)	ta="$ta epiphany-asm.lo epiphany-desc.lo epiphany-dis.lo epiphany-ibld.lo epiphany-opc.lo" using_cgen=yes ;;
	bfd_iq2000_arch)	ta="$ta iq2000-asm.lo iq2000-desc.lo iq2000-dis.lo iq2000-ibld.lo iq2000-opc.lo" using_cgen=yes ;;
	bfd_lm32_arch)		ta="$ta lm32-asm.lo lm32-desc.lo lm32-dis.lo lm32-ibld.lo lm32-opc.lo lm32-opinst.lo" using_cgen=yes ;;
	bfd_m32c_arch)		ta="$ta m32c-asm.lo m32c-desc.lo m32c-dis.lo m32c-ibld.lo m32c-opc.lo" using_cgen=yes ;;
	bfd_m32r_arch)		ta="$ta m32r-asm.lo m32r-desc.lo m32r-dis.lo m32r-ibld.lo m32r-opc.lo m32r-opinst.lo" using_cgen=yes ;;
	bfd_m68hc11_arch)	ta="$ta m68hc11-dis.lo m68hc11-opc.lo" ;;
	bfd_m68hc12_arch)	ta="$ta m68hc11-dis.lo m68hc11-opc.lo" ;;
	bfd_m9s12x_arch)	ta="$ta m68hc11-dis.lo m68hc11-opc.lo" ;;
	bfd_m9s12xg_arch)	ta="$ta m68hc11-dis.lo m68hc11-opc.lo" ;;
	bfd_s12z_arch)		ta="$ta s12z-dis.lo s12z-opc.lo" ;;
	bfd_m68k_arch)		ta="$ta m68k-dis.lo m68k-opc.lo" ;;
	bfd_mcore_arch)		ta="$ta mcore-dis.lo" ;;
	bfd_mep_arch)		ta="$ta mep-asm.lo mep-desc.lo mep-dis.lo mep-ibld.lo mep-opc.lo" using_cgen=yes ;;
	bfd_metag_arch)		ta="$ta metag-dis.lo" ;;
	bfd_microblaze_arch)	ta="$ta microblaze-dis.lo" ;;
	bfd_mips_arch)		ta="$ta mips-dis.lo mips-opc.lo mips16-opc.lo micromips-opc.lo" ;;
	bfd_mmix_arch)		ta="$ta mmix-dis.lo mmix-opc.lo" ;;
	bfd_mn10200_arch)	ta="$ta m10200-dis.lo m10200-opc.lo" ;;
	bfd_mn10300_arch)	ta="$ta m10300-dis.lo m10300-opc.lo" ;;
	bfd_mt_arch)		ta="$ta mt-asm.lo mt-desc.lo mt-dis.lo mt-ibld.lo mt-opc.lo" using_cgen=yes ;;
	bfd_msp430_arch)	ta="$ta msp430-dis.lo msp430-decode.lo" ;;
	bfd_nds32_arch)		ta="$ta nds32-asm.lo nds32-dis.lo" ;;
	bfd_nfp_arch)		ta="$ta nfp-dis.lo" ;;
	bfd_nios2_arch)		ta="$ta nios2-dis.lo nios2-opc.lo" ;;
	bfd_ns32k_arch)		ta="$ta ns32k-dis.lo" ;;
	bfd_or1k_arch)		ta="$ta or1k-asm.lo or1k-desc.lo or1k-dis.lo or1k-ibld.lo or1k-opc.lo" using_cgen=yes ;;
	bfd_pdp11_arch)		ta="$ta pdp11-dis.lo pdp11-opc.lo" ;;
	bfd_pj_arch)		ta="$ta pj-dis.lo pj-opc.lo" ;;
	bfd_powerpc_arch)	ta="$ta ppc-dis.lo ppc-opc.lo" ;;
	bfd_powerpc_64_arch)	ta="$ta ppc-dis.lo ppc-opc.lo" ;;
	bfd_pru_arch)		ta="$ta pru-dis.lo pru-opc.lo" ;;
	bfd_pyramid_arch)	;;
	bfd_romp_arch)		;;
	bfd_riscv_arch)         ta="$ta riscv-dis.lo riscv-opc.lo" ;;
	bfd_rs6000_arch)	ta="$ta ppc-dis.lo ppc-opc.lo" ;;
	bfd_rl78_arch)		ta="$ta rl78-dis.lo rl78-decode.lo";;
	bfd_rx_arch)		ta="$ta rx-dis.lo rx-decode.lo";;
	bfd_s390_arch)		ta="$ta s390-dis.lo s390-opc.lo" ;;
	bfd_score_arch)		ta="$ta score-dis.lo score7-dis.lo" ;;
	bfd_sh_arch)		ta="$ta sh-dis.lo cgen-bitset.lo" ;;
	bfd_sparc_arch)		ta="$ta sparc-dis.lo sparc-opc.lo" ;;
	bfd_spu_arch)		ta="$ta spu-dis.lo spu-opc.lo" ;;
	bfd_tic30_arch)		ta="$ta tic30-dis.lo" ;;
	bfd_tic4x_arch)		ta="$ta tic4x-dis.lo" ;;
	bfd_tic54x_arch)	ta="$ta tic54x-dis.lo tic54x-opc.lo" ;;
	bfd_tic6x_arch)		ta="$ta tic6x-dis.lo" ;;
	bfd_tilegx_arch)	ta="$ta tilegx-dis.lo tilegx-opc.lo" ;;
	bfd_tilepro_arch)	ta="$ta tilepro-dis.lo tilepro-opc.lo" ;;
	bfd_v850_arch)		ta="$ta v850-opc.lo v850-dis.lo" ;;
	bfd_v850e_arch)		ta="$ta v850-opc.lo v850-dis.lo" ;;
	bfd_v850ea_arch)	ta="$ta v850-opc.lo v850-dis.lo" ;;
	bfd_v850_rh850_arch)	ta="$ta v850-opc.lo v850-dis.lo" ;;
	bfd_vax_arch)		ta="$ta vax-dis.lo" ;;
	bfd_visium_arch)	ta="$ta visium-dis.lo visium-opc.lo" ;;
        bfd_wasm32_arch)        ta="$ta wasm32-dis.lo" ;;
	bfd_xc16x_arch)		ta="$ta xc16x-asm.lo xc16x-desc.lo xc16x-dis.lo xc16x-ibld.lo xc16x-opc.lo" using_cgen=yes ;;
	bfd_xgate_arch)		ta="$ta xgate-dis.lo xgate-opc.lo" ;;
	bfd_xstormy16_arch)	ta="$ta xstormy16-asm.lo xstormy16-desc.lo xstormy16-dis.lo xstormy16-ibld.lo xstormy16-opc.lo" using_cgen=yes ;;
	bfd_xtensa_arch)	ta="$ta xtensa-dis.lo" ;;
	bfd_z80_arch)		ta="$ta z80-dis.lo" ;;
	bfd_z8k_arch)		ta="$ta z8k-dis.lo" ;;
	bfd_bpf_arch)		ta="$ta bpf-asm.lo bpf-desc.lo bpf-dis.lo bpf-ibld.lo bpf-opc.lo" using_cgen=yes ;;
	bfd_loongarch_arch)	ta="$ta loongarch-dis.lo loongarch-opc.lo loongarch-coder.lo" ;;
	"")			;;
	*)		AC_MSG_ERROR(*** unknown target architecture $arch) ;;
	esac
    done
vM ★★
()
Последнее исправление: vM (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.