[Bug 2114178] [NEW] Can't load 32-bit ELF to target with gdb-multiarch

[Fighter19]

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
Foundations Bugs, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/2114178

Title:
  Can't load 32-bit ELF to target with gdb-multiarch

Status in gdb package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2114178/+subscriptions