Re: Poke utility pk-elfextractor

[Indu Bhagat]

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
> > 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

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
> > |............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.

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.

Thanks,
Indu