Re: Poke utility pk-elfextractor

[Jose E. Marchesi]

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 
> pk-elfextractor?

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
poke/poke/pk-save.pk).

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

>
> $ 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
> |............7...|
> 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.
>
> Thanks
> Indu