bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mes] M2-Planet test23


From: Danny Milosavljevic
Subject: Re: [bug-mes] M2-Planet test23
Date: Sat, 6 Apr 2019 17:15:47 +0200

Hi Jeremiah,

On Sat, 06 Apr 2019 14:47:48 +0000
address@hidden wrote:

> If you set the PT-LOAD to 0 in :ELF_program_header__data it will just
> load as a text section; which will work for removing that error message.
> So we can certainly perform that change for any program that doesn't
> have any globals in the program that need to be modified or we could
> disable the PT-LOAD of the Text section (or change it's flags to allow
> write) for the programs with global variables.

Technically, we can have the virtual address be whatever we want (including 
huge gaps) so there's no reason to have the overlap in the first place.

> However, the fault remains and thus the problem might not be in the
> header

>(despite it's flaws it kinda works).

Not really--it segfaults right on startup before reaching the entry point.
The Linux binfmt elf loader rejects that file.

Maybe it works in qemu--but there the debugging tools are much more limited.
(I can't even get gdb to work reliably in the qemu arm transparent emulation)

I've tried the PT-LOAD=0 workaround now, it dumps core now (immediately after
entering main--same as test21).

(for comparison, test20 works fine)

Instructions are

       ldr r0, [pc]
       b <+12>
       <96600 decimal here>
<+12>: stmfd sp!, {r0}
       ldr r0, [pc]
       b <+28>
       <1 decimal here>
<+28>: andeq r0, r0, r1
       ldmfd sp!, {r1}
       str r0, [r1]     <====== crash here

r1 is 97600 decimal (0x17d40).  That's in a read-only segment.

Attachment: pgp6gsbJqXrw9.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]