Kedbg with SIGABRT and SEGFAULT on static and dynamic modes (ARM ELF)

[thorkill]

I've been trying X commands on both modes, static and dynamic, and there seems to be an issue on revm_hexa_display(). Elfsh works with the elf in question and that's why I'm opening this related to kedbg.

I'm sending the elf file and a txt with everything I tried on kedbg prompt, and the backtrace I run after it. In summary I do:

• X .vectors%32
• X .data_run%32

Both in static and dynamic mode. The .vectors section goes ok on static but I have a SIGABRT on dynamic, and on the .data_run I have SEGFAULT on both.

The txt file has the biggest output truncated, because it was not interesting at all.

Sections list: http://pastebin.com/m5a4a7379 Elf Header: http://pastebin.com/m49cfddb1 Program Header: http://pastebin.com/m3a8cd14

---

Ticket: 122 Reported by: forger on Thu Apr 23 16:16:02 2009 attachment: kedbg_tests.txt/ attachment: rtosdemo.elf/

[thorkill]

[forger] After a closer look at this on gdb I found this:

profiler_err (file=0xb7e398e1 "vectors_default.c", func=0xb7e39a7e "elfsh_default_readmema", line=26, msg=0xb7e371b8 "Unsupported Arch, ELF type, or OS") at profiler.c:406

This comes after the "buff = elfsh_readmema(parent->parent, wheretoread, bufarg, readnow);" call, at libstderesi/elf/disasm.c:597.

I'm attaching a core dump now.

[thorkill]

[forger] Core is >2MB. Download it here if you need it: http://www.2shared.com/file/5467115/98653076/core.html

Replying to [comment:1 forger]:

After a closer look at this on gdb I found this:

profiler_err (file=0xb7e398e1 "vectors_default.c", func=0xb7e39a7e "elfsh_default_readmema", line=26, msg=0xb7e371b8 "Unsupported Arch, ELF type, or OS") at profiler.c:406

This comes after the "buff = elfsh_readmema(parent->parent, wheretoread, bufarg, readnow);" call, at libstderesi/elf/disasm.c:597.

I'm attaching a core dump now.

[thorkill]

[forger] After one more debugging session I was able to to see that the iotype when running the same commands on elfsh and kedbg differ from each other. While at elfsh we have a iotype=0, at kedbg we have iotype=2. The ostype is 8 on both (ARM, so it's correct). [[BR]]

At vectors_call.c:446, elfsh_readmema(), we have this fct = aspect_vectors_select(mem, dim); This mem parameter is a vector_t:[[BR]] {hook = 0x8068620, register_func = 0x0, default_func = 0xb7e9c2c0, arraydims = 0x80681a0, strdims = 0x80681b8, arraysz = 2, type = 0}

With iotype=2 (kedbg), the function pointer fct gets a return value from aspect_vectors_select() that makes it a pointer to elfsh_default_readmema(). On elfsh, with iotype=0, this doesn't happen and we have a pointer to elfsh_get_raw_by_addr(). [[BR]]

So, the main question now is: why different iotype values (2 on kedbg and 0 on elfsh) for the same elf file ?

[thorkill]

[forger] :P, well, off course that iotype is not elf file related. Iotype on elfsh is 0 because it is ELFSH_IOTYPE_STATIC, and it is 2 on kedbg because it's ELFSH_IOTYPE_GDBPROT.

This might be just some missing handlers on hooks.c, for ELFSH_OSTYPE_ARM and ELFSH_IOTYPE_GDBPROT. Patching now... :)