[Bug 269568] strip(1) creates an executable which crashes in ld-elf.so.1

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269568

Fernando Apesteguía <fernape@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
            Version|13.1-RELEASE                |CURRENT
                 CC|                            |fernape@FreeBSD.org

--- Comment #1 from Fernando Apesteguía <fernape@FreeBSD.org> ---
The program fails in this line

memset(&objtmp, 0, sizeof(objtmp));

in 

static void                                                                    
init_rtld(caddr_t mapbase, Elf_Auxinfo **aux_info)

in rtld.c

objtmp is already zeroed and its address is 

(gdb) p &objtmp
$9 = (Obj_Entry *) 0x7fffffffe150

which is not addressable.

After creating the jdupes executable with LOW_MEMORY=1, we can inspect the ELF
of the original file and the files stripped with strip(1) in base (fails), gnu
strip and llvm-strip (both work). Having a look at the headers,

The relocation information for the versions that work is this:

 GNU_RELRO      0x0000000000007400 0x0000000000209400 0x0000000000209400
                 0x00000000000001a0 0x0000000000000c00  R      0x1

which is different from the header generated by strip(1):

GNU_RELRO      0x0000000000007400 0x0000000000209400 0x0000000000209400
                 0x00000000000001a0 0x00000000000001a0  R      0x1

Notice how MemSiz is smaller in the latter case (1a0 vs c00).

There is another difference that I can spot. In the three versions that work,
this is the GNU_STACK header:

 GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000001000000  RW     0

But strip(1) generates this:

GNU_STACK      0x0000000000000000 0x000000000020a770 0x0000000000000000
                 0x0000000000000000 0x0000000000002308  RW     0

Again, the MemSiz is much smaller in this case.

However, the .bss section in all four executables is identical:

 [25] .bss              NOBITS           000000000020a770  00007768
       0000000000002308  0000000000000000  WA       0     0     16

Changing Version to CURRENT since it fails there too.

-- 
You are receiving this mail because:
You are the assignee for the bug.