diff options
author | aszlig <aszlig@nix.build> | 2022-09-18 13:20:20 +0200 |
---|---|---|
committer | aszlig <aszlig@nix.build> | 2022-09-18 13:20:20 +0200 |
commit | f7cacf7fd58f79ff3ddaaa6fff87425090167ebd (patch) | |
tree | e8660ca46402dd50f3166227e792c1599efc196c /pkgs/games/humblebundle/antichamber.nix | |
parent | d27c8bc427251882e1dc861d0499170965b6720d (diff) |
radare2: Add patch to default to AT&T ASM syntax
Some personal history on this: I started to get used to AT&T syntax because it's the default in GDB and used that ever since until I one day starting to do some more reverse engineering using radare, which defaults to Intel syntax. Ever since then probably my most used command in GDB was "set disassembly-flavor intel" (because I was to lazy to add it to the config) because I constantly got confused by the source/destination operand swaps. This even happened during live reverse engineering at rC3 where I was confused about some function logic only to find out that I was viewing in AT&T syntax. Fast-forward to today: I'm debugging some application using WINE and winedbg uses AT&T syntax, which I didn't like at first. After reflecting on this for a while, I thought it would probably be better to get used to AT&T syntax again and switch everything to use AT&T for the following reasons: * Operands are more natural to read, since most libraries/APIs in higher level languages do it like this (well, except memcpy, strcpy, etc... maybe I now get confused by libc functions...) * AT&T syntax feels less verbose, for example "mov ecx, dword [eax]" is just "movl (%eax), %ecx" This very commit makes sure that radare2 now defaults to AT&T syntax instead of eg. ensuring that GDB uses Intel syntax by default. Signed-off-by: aszlig <aszlig@nix.build>
Diffstat (limited to 'pkgs/games/humblebundle/antichamber.nix')
0 files changed, 0 insertions, 0 deletions