C++ code compiles with release build, fails with debug build (/D_DEBUG); MSVC obviously
Expectation: define _DEBUG (or switching between release and debug build) doesn’t change whether code is accepted; apparently Mircosoft has a different view...
// source code, x.cpp #include <cstdio> #include <string> static constexpr std::string s = “asdf”; int main() { printf(“%s\n”, s.c_str()); }Compile with debug:
cl /std:c++20 /D_DEBUG x.cpp Microsoft ® C/C++ Optimizing Compiler Version 19.39.33520 for x64 Copyright © Microsoft Corporation. All rights reserved. x.cpp x.cpp(4): error C2131: expression did not evaluate to a constant x.cpp(4): note: (sub-)object points to memory which was heap allocated during constant evaluationCompile as release:
cl /std:c++20 x.cpp Microsoft ® C/C++ Optimizing Compiler Version 19.39.33520 for x64 Copyright © Microsoft Corporation. All rights reserved. x.cpp Microsoft ® Incremental Linker Version 14.39.33520.0 Copyright © Microsoft Corporation. All rights reserved. /out:x.exe x.obj
Bonus: when the initializer string “asdf” is longer, e.g. “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasdf” also the release build fails (which is OK)
There's actually a very good and detailed technical explanation.
posted at: 10:00 | path: /programming | permanent link
Configuring editors to not append a newline at the end (before the end-of-file, EOF):
nano -L
or put set nonewlines
in ~/.nanorc
gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false
(see here also)
posted at: 23:13 | path: /programming | permanent link
Got a 11x44 LED badge labelled S1144. It identifies as
usb 1-2: new full-speed USB device number 61 using xhci_hcd usb 1-2: New USB device found, idVendor=0416, idProduct=5020, bcdDevice= 1.00 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2: Product: CH546 usb 1-2: Manufacturer: wch.cn hid-generic 0003:0416:5020.0090: hiddev1,hidraw2: USB HID v1.00 Device [wch.cn CH546] on usb-0000:02:00.0-2/input0The CH546 is a 8051 MCU. It uses a USB HID interface. There is some Windows software to program it.
Here's what lsusb -v -v -v
has to say about it:
Bus 001 Device 062: ID 0416:5020 Winbond Electronics Corp. CH546 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0416 Winbond Electronics Corp. idProduct 0x5020 bcdDevice 1.00 iManufacturer 1 wch.cn iProduct 2 CH546 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0029 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 wch.cn bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 70mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 5 wch.cn HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 34 Report Descriptor: (length is 34) Item(Global): Usage Page, data= [ 0x00 0xff ] 65280 (null) Item(Local ): Usage, data= [ 0x01 ] 1 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Local ): Usage, data= [ 0x02 ] 2 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x00 0xff ] 65280 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x40 ] 64 Item(Main ): Input, data= [ 0x06 ] 6 Data Variable Relative No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage, data= [ 0x02 ] 2 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x00 0xff ] 65280 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x40 ] 64 Item(Main ): Output, data= [ 0x06 ] 6 Data Variable Relative No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Device Status: 0x0000 (Bus Powered)
posted at: 21:22 | path: /programming | permanent link
On x86 (32-bit), a no-operation (nop) can be encoded as a CPU instruction 0x90 (among other choices).
0x90 can also be interpreted as xchg eax,eax
.
On x86-64, xchg eax, eax
is not a nop, as it clear the upper-half of the rax register; hence, it must be encoded as 0x87 0xc0.
xchg rax, rax
could be translated into a nop.
radare's rasm2
allows to easily experiment with different assembler engines for x86 (.nz is default):
rasm2 -a x86.nz -b 64 "xchg eax,eax" // .nz .. handmade assembler 87c0 rasm2 -a x86.nz -b 32 "xchg eax,eax" 90 rasm2 -a x86.nasm -b 64 "xchg rax,rax" // using NASM, notice the extra override byte 0x48 4890 rasm2 -a x86.as -b 64 "xchg rax,rax" // using GNU assembler 90
At least the following libraries/tools get this wrong:
As you might have guessed, these are my Hacktoberfest 2022 contributions.
posted at: 12:54 | path: /programming | permanent link
qemu can emulate all kind of architectures and processors, including x86 and x86_64, it has presets for a long list of CPUs ([1], 486, pentium, Haswell, etc.)
I've tried this using qemu 4.2.1 on Ubuntu 20.04, latest is 5.1.0.
qemu does full-system emulation AND user-mode emulation. While the former allows to run a wide range of operating systems on any supported architecture [2], the later runs programs for another Linux or BSD target.
Full-system User-mode +---------------------+ +---------------------+ | Userspace emulation | | Userspace emulation | +----------+----------+ +----------+----------+ | | +---------+--------+ +-------+-------+ | Kernel emulation | | Kernel native | +---------+--------+ +-------+-------+ | | +----------+---------+ +--------+--------+ | Hardware emulation | | Hardware native | +--------------------+ +-----------------+
Let's compile the following simple program (hello.c
):
#include <stdio.h> int main() { printf("hello world %p\n", main); return 0; }And link statically to be self-contained; qemu can handle dynamically linked executables just fine as well.
To compile and link for 32-bit ARM [3]: arm-linux-gnueabihf-gcc -static -o hello-arm hello.c
For 64-bit x86: gcc -static -o hello-x86_x64 hello.c
Let's check:
$ file hello-arm
hello-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, not stripped$ file hello-x86_x64
hello-x86_x64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, not stripped
On Ubuntu, we need qemu-user [4], and can then execute both binaries:
$ qemu-arm -- ./hello-arm
hello world 0x10425$ qemu-x86_64 -- ./hello-x86_64
hello world 0x401ce5
qemu translates the input binary to run on the native CPU, also in
case the architectures match. It uses internal micro ops (some intermediate representation), these can be observed before and after
optimization:
qemu-x86_64 -d op -- ./hello-x86_64
qemu-x86_64 -d op_opt -- ./hello-x86_64
For example:
mov_i64 tmp0,r13 mov_i64 tmp1,r13 and_i64 cc_dst,tmp0,tmp1 discard cc_src discard loc10
Also the input and output assembler code can be seen:
qemu-x86_64 -d in_asm -- ./hello-x86_x64
qemu-x86_64 -d out_asm -- ./hello-x86_x64
qemu -cpu help
apt install gcc-arm-linux-gnueabihf
apt install qemu-user
qemu-x86_64 -d help
posted at: 23:45 | path: /programming | permanent link