Bug 396476 - Reading debug info of binaries with zero-size PT_LOAD segment
Summary: Reading debug info of binaries with zero-size PT_LOAD segment
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.14 SVN
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on: 395682
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-13 14:51 UTC by H.J. Lu
Modified: 2023-11-19 07:42 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
A test program (1.41 KB, application/x-xz)
2018-07-13 14:51 UTC, H.J. Lu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2018-07-13 14:51:45 UTC
Created attachment 113918 [details]
A test program

Here is a tiny program:

https://github.com/hjl-tools/simple-linux/tree/divide-by-zero

Valgrind can't read its DWARF debug info with zero-size PT_LOAD segment:

[hjl@gnu-cfl-1 simple-linux]$ make LD=ld.gold
gcc -g -O0   -c -o test.o test.c
test.c: In function \u2018main\u2019:
test.c:22:9: warning: division by zero [-Wdiv-by-zero]
   i = 7 / 0;
         ^
gcc -g   -c -o start.o start.S
gcc -g   -c -o syscall.o syscall.S
ld.gold  -o test test.o start.o syscall.o
./test hello world
a
make: *** [Makefile:12: all] Floating point exception
[hjl@gnu-cfl-1 simple-linux]$ valgrind ./test
==27555== Memcheck, a memory error detector
==27555== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27555== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==27555== Command: ./test
==27555== 
a
==27555== 
==27555== Process terminating with default action of signal 8 (SIGFPE)
==27555==  Integer divide by zero at address 0x1002B95532
==27555==    at 0x40015E: ??? (in /export/ssd/git/github/simple-linux/test)
==27555==    by 0x4001A8: ??? (in /export/ssd/git/github/simple-linux/test)
==27555== 
==27555== HEAP SUMMARY:
==27555==     in use at exit: 0 bytes in 0 blocks
==27555==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==27555== 
==27555== All heap blocks were freed -- no leaks are possible
==27555== 
==27555== For counts of detected and suppressed errors, rerun with: -v
==27555== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Floating point exception
[hjl@gnu-cfl-1 simple-linux]$ gdb test
GNU gdb (GDB) Fedora 8.1-19.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...done.
(gdb) r
Starting program: /export/ssd/git/github/simple-linux/test 
a

Program received signal SIGFPE, Arithmetic exception.
0x000000000040015c in main (argc=1, argv=0x7fffffffd708) at test.c:22
22	  i = 7 / 0;
(gdb)

[hjl@gnu-cfl-1 simple-linux]$ readelf -lW test

Elf file type is EXEC (Executable file)
Entry point 0x40019a
There are 3 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000240 0x000240 R E 0x1000
  LOAD           0x001000 0x0000000000401000 0x0000000000401000 0x000000 0x000000 RW  0x1000
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .text .rodata .eh_frame 
   01     .data .bss 
   02     
[hjl@gnu-cfl-1 simple-linux]$
Comment 1 Paul Floyd 2023-11-19 07:38:46 UTC
This is not straightforward. The segment loading code ignores zero sized segments. But the precondition for loading debuginfo is that an RX and one or two RW segments have been loaded.

What I think that I need to do is add some dummy handler for zero-sized RW segments that just trigger the debuginfo loading.
Comment 2 Paul Floyd 2023-11-19 07:42:31 UTC
(In reply to Paul Floyd from comment #1)

> What I think that I need to do is add some dummy handler for zero-sized RW
> segments that just trigger the debuginfo loading.

I can reproduce the problem on FreeBSD. Using ld.lld I get

paulf> readelf -lW test

Elf file type is EXEC (Executable file)
Entry point 0x20128a
There are 4 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000200040 0x0000000000200040 0x000118 0x000118 R   0x8
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x0001d4 0x0001d4 R   0x1000
  LOAD           0x0001e0 0x00000000002011e0 0x00000000002011e0 0x0000da 0x0000da R E 0x1000
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .rodata .eh_frame 
   02     .text 
   03    

So this doesn't even have a zero sized RW segment.

That's even worse.