Re: [PATCH] Skip PT_DYNAMIC segment if its p_filesz == 0 [BZ #22101]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On 9/25/17, Zack Weinberg <zackw@panix.com> wrote:
> On Mon, Sep 25, 2017 at 9:12 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On 9/25/17, Zack Weinberg <zackw@panix.com> wrote:
>>> On Mon, Sep 25, 2017 at 8:33 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> ELF object generated with "objcopy --only-keep-debug" has
>>>>
>>>> Type     Offset  VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>>>> DYNAMIC  0x0+e28 0x0+200e40 0x0+200e40 0x0+    0x0+1a0 RW  0x8
>>>>
>>>> with 0 file size. ld.so should skip such PT_DYNAMIC segments.
>>>
>>> Why should ld.so skip such PT_DYNAMIC segments?  It seems like loading
>>> empty segments should be harmless, and ...
>>
>> Not all valid segments can have zero p_filesz.  The valid PT_DYNAMIC
>> segment
>> should have non-zero p_filesz.
>
> Argh, I misremembered what a PT_DYNAMIC segment is.  I've checked the
> gABI now and I see that it specifies that an empty PT_DYNAMIC segment
> is in fact invalid in a shared object (since certain entries in the
> array are mandatory) ... but the change still makes me nervous.  What
> _exactly_ does our ld.so do with this now, in the absence of your
> change?  If it does anything other than crash, I fear there may be

ld.so simply crashes without my change:

Starting program:
/export/build/gnu/glibc/build-x86_64-linux/elf/tst-debug1 --direct

Program received signal SIGSEGV, Segmentation fault.
_dl_relocate_object (scope=0x604608, reloc_mode=reloc_mode@entry=1,
    consider_profiling=consider_profiling@entry=0) at dl-reloc.c:231
231	    const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
(gdb) bt
#0  _dl_relocate_object (scope=0x604608, reloc_mode=reloc_mode@entry=1,
    consider_profiling=consider_profiling@entry=0) at dl-reloc.c:231
#1  0x00007ffff7dea573 in dl_open_worker (a=a@entry=0x7fffffffd910) at
dl-open.c:422
#2  0x00007ffff794c86c in __GI__dl_catch_exception (exception=0x7fffffffd8f0,
    operate=0x7ffff7dea310 <dl_open_worker>, args=0x7fffffffd910)
    at dl-error-skeleton.c:196
#3  0x00007ffff7de9f6a in _dl_open (file=0x401cd8 "tst-debug1mod1.so",
mode=-2147483647,
    caller_dlopen=0x401323 <do_test+19>, nsid=<optimized out>, argc=2,
    argv=<optimized out>, env=0x7fffffffdd30) at dl-open.c:645
#4  0x00007ffff7bd3f06 in dlopen_doit (a=a@entry=0x7fffffffdb40) at dlopen.c:66
#5  0x00007ffff794c86c in __GI__dl_catch_exception (
    exception=exception@entry=0x7fffffffdae0, operate=0x7ffff7bd3eb0
<dlopen_doit>,
    args=0x7fffffffdb40) at dl-error-skeleton.c:196
#6  0x00007ffff794c8df in __GI__dl_catch_error (objname=0x7ffff7dd60d0
<last_result+16>,
    errstring=0x7ffff7dd60d8 <last_result+24>,
mallocedp=0x7ffff7dd60c8 <last_result+8>,
    operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:215
#7  0x00007ffff7bd4525 in _dlerror_run (
    operate=operate@entry=0x7ffff7bd3eb0 <dlopen_doit>,
args=args@entry=0x7fffffffdb40)
    at dlerror.c:162
#8  0x00007ffff7bd3f81 in __dlopen (file=file@entry=0x401cd8
"tst-debug1mod1.so",
    mode=mode@entry=1) at dlopen.c:87
#9  0x0000000000401323 in do_test () at tst-debug1.c:25
#10 0x00000000004017a3 in support_test_main (argc=1, argv=0x7fffffffdd20,
    config=config@entry=0x7fffffffdbe0) at support_test_main.c:321
#11 0x0000000000401225 in main (argc=<optimized out>, argv=<optimized out>)
    at ../support/test-driver.c:164
(gdb)

> programs out there relying on the behavior.
>
> (And I'd like you to specifically check that your change doesn't break
> GDB's ability to load debug-only objects, even though I'm pretty sure
> it doesn't use dlopen to do it.)
>

GDB doesn't call dlopen to load debug-only objects.

-- 
H.J.