[Top][All Lists]

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

Re: Poke utility pk-elfextractor

From: Indu Bhagat
Subject: Re: Poke utility pk-elfextractor
Date: Sat, 20 Feb 2021 23:45:28 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

On 2/20/21 3:20 AM, Jose E. Marchesi wrote:

Hi Indu.

I was trying to use the Poke utility pk-elfextractor and found that
perhaps it needs a fix as follows :

diff --git a/utils/pk-elfextractor.in b/utils/pk-elfextractor.in
index adb57b53..669e53b9 100755
--- a/utils/pk-elfextractor.in
+++ b/utils/pk-elfextractor.in
@@ -37,7 +37,7 @@ try

      for (shdr in elf.shdr where shdr.sh_type != 0x0)
-        var sname = elf.get_string (shdr.sh_name);
+        var sname = elf.get_section_name (shdr.sh_name);

Yes indeed.

          if (section_name == "" || sname == section_name)
            save :ios elf'ios :file file_name + sname

Now, after the fix, I was expecting the output file to be containing
only the requested section. However, I am seeing some zero'd out bytes
at the beginning of the output files.

Looks like some buffered/zero'd out bytes are being flushed out to the
output file. Can someone confirm what is the expected behavior of

It is not.  elfextracor is supposed to write to the file the bytes
corresponding to the contents of the selecting sections, i.e.

           save :ios elf'ios :file file_name + sname
                :from shdr.sh_offset :size shdr.sh_size;

This may be a bug in the `save' command (implemented in

Are you able to reproduce it interactively:

(poke) file foo.o
(poke) load elf
(poke) var elf = Elf64_File @ 0#B
(poke) var ctfsec = elf.get_section_by_name (".ctf")
(poke) save :file "foo.out" :from ctfsec.sh_offset :size ctfsec.sh_size

Yes. This problem is reproducible interactively.

You were right. The problem was in pk-save.pk. We need to use the output_offset as the offset to copy to. So, the following fixes the problem:

diff --git a/poke/pk-save.pk b/poke/pk-save.pk
index ec2a23cb..6d5eae88 100644
--- a/poke/pk-save.pk
+++ b/poke/pk-save.pk
@@ -86,7 +86,7 @@ fun save = (int ios = get_ios,
    output_offset = iosize (file_ios);

  /* Copy the stuff.  */
- copy :from_ios ios :to_ios file_ios :from from :size size;
+ copy :from_ios ios :to_ios file_ios :from from :to output_offset :size size;

  /* Cleanup.  */
  close (file_ios);

$ hexdump -C ctf-enum-1.o.ctf
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000040  f2 df 04 02 00 00 00 00  00 00 00 00 37 00 00 00
00000050  00 00 00 00 00 00 00 00  04 00 00 00 04 00 00 00

Note how the bytes starting at 0x40 is the CTF magic number (0xdff2).

A perhaps orthogonal problem is that a CTF_Section @ 64#B fails with a
"unhandled constraint violation exception". A visual comparison of
bytes does not show any problems when compared to the .ctf section
from the original object file (ctf-enum-1.o). But I will get to that
bridge once I know what to expect from pk-elfextractor.

Ignore this. I needed to set the endianness to little and now the binary ctf files output by using pk-elfextractor can be mapped using ctf pickle.


reply via email to

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