Public bug reported:
OS: Ubuntu 24.04.1 LTS
Version: 15.0.50.20240403-0ubuntu1
Target: PIC32MM (MIPS32 rel2 version 1)
ELF parser badly extends 32-bit address with sign.
Summary:
While trying to flash a device from an ELF with an address that is higher than
0x7ffffff,
the memory write request is too large, as it's expanded with 0xf.
This leads to function claim_memory not putting the request into the
appropriate vector and results in failure loading:
Problem:
(gdb) load test.elf
Loading section .reset, size 0x10 lma 0xbfc00000
Laden fehlgeschlagen
Analysis:
By setting a breakpoint at target-memory.c:58, it can be observed how "begin"
and "end" of the write requests are too big (on the gdb, debugging gdb):
(gdb) b target-memory.c:58
(gdb) c
Continuing.
Thread 1 "gdb-multiarch" hit Breakpoint 8, claim_memory (end=2147483648,
begin=0, result=0x7ffc33cbb2b0, blocks=std::vector of length 1, capacity 1 =
{...})
at /build/gdb-1WjiBe/gdb-15.0.50.20240403/gdb/target-memory.c:58
58 in /build/gdb-1WjiBe/gdb-15.0.50.20240403/gdb/target-memory.c
(gdb) p r
$46 = (const memory_write_request &) @0x5fa3e8ef6e10: {begin =
18446744072631615488, end = 18446744072631615504, data = 0x5fa3e8ecc650 "\002",
baton = 0x5fa3e8f9abd0}
(gdb) p /x r.begin
$48 = 0xffffffffbfc00000
It would be expected to return just 0xbfc00000 here.
objdump also properly prints this and the info message is also correctly
formatted, implying this is caused due to an underlying int vs uint
conversion problem.
objdump -x test.elf
test.elf: file format elf32-little
test.elf
architecture: UNKNOWN!, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0xbfc00000
Program Header:
LOAD off 0x00000074 vaddr 0x9d000000 paddr 0x00000000 align 2**16
filesz 0x00000000 memsz 0x00000000 flags r-x
LOAD off 0x00010000 vaddr 0xbfc00000 paddr 0xbfc00000 align 2**16
filesz 0x00000010 memsz 0x00000010 flags r-x
Sections:
Idx Name Size VMA LMA File off Algn
0 .reset 00000010 bfc00000 bfc00000 00010000 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
SYMBOL TABLE:
bfc00000 l d .reset 00000000 .reset
bfc00008 g O .reset 00000000 _startup
This problem can be worked around by using objcopy to create an ihex file
first, then loading that.
Setting a break, will show a proper value with an ihex file, namely 0xbfc00000
being used.
By modifying the test file using objcopy it can also be noted, that this
problem only occurs with addresses where the highest bit is set.
** Affects: gdb (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "Small test executable which will just loop infinitely"
https://bugs.launchpad.net/bugs/2114178/+attachment/5883631/+files/test.elf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2114178
Title:
Can't load 32-bit ELF to target with gdb-multiarch
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2114178/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
