frv fdpic: don't mess with the stack segment when stripping
Alexandre Oliva
aoliva@redhat.com
Thu May 6 03:03:00 GMT 2004
This patch arranges for strip and objcopy to propagate the stack size
and alignment information, that FRV FDPIC encodes in the PT_GNU_STACK
PHDR.
The problem is that, since PT_GNU_STACK doesn't contain any sections,
when we compute the phdrs for the new executable, it comes out empty.
I was hoping the bfd_copy_private_bfd_data entry point would be able
to adjust it, but objcopy calls it too late for the changes to phdr to
have any effect: they've already been written out to disk.
I don't quite see how I could add a new bfd entry point to copy phdr
information at the point I'd need it: within
assign_file_positions_for_segments(), that creates the phdrs data
structure and writes them to disk, we don't have access to the phdrs
of the executable being copied.
So I figured the only ways I could make it work were to (i) arrange
for the entry point that modified the phdrs after they were written
out to write them again, or (ii) get objcopy to write the phdrs again
after calling copy_private_bfd_data (but how would it know how to do
it?). I thought I'd limit my change to frv-specific files only, so I
the patch below does (i). Is this approach reasonable? It works, but
I'm a bit worried about seeking and modifying obfd's file within this
function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bfd-frv-strip-preserve-stack.patch
Type: text/x-patch
Size: 2792 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040506/d5ccc030/attachment.bin>
-------------- next part --------------
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
More information about the Binutils
mailing list