SVR4 ELF access library question... (ELF-specific)

SVR4 ELF access library question... (ELF-specific)

Post by Farooq Bu » Sun, 03 Nov 1991 06:52:33



Folks-

This'll only make sense to those of you who've spent a few hours
curled up with the SVR4 ELF access library but...here goes...  I have
a weird situation with the AT&T SYS 5.4 ELF access library.  I am
using it to copy one section (actually the .debug section) to another
in an ELF file.  Data is copied from one section into intermediate
data structures and then piped back out to a new ELF file using
elf_newdata().  Here's the weird situation: my data is aligned on
4-byte boundaries (i.e.  data->d_align == 4), I am copying file A to
file B and the ELF access library, all copying seems to go OK UNTIL we
get to the end of data, where I see that the ELF access DROPS my last
padding DIE.  The padding DIE was originally generated by pcc.

fileA:
$ dump -s -n .debug fileA

test:

.debug:
        0000  002d  0011  0012  0000  0104  0038  7465  7374  2e63  0001  3600
        0000  0101  1100  0013  f001  2100  0014  2801  0600  0000  0000  0000
        2300  0600  1200  0000  fb00  386d  6169  6e00  0055  0007  0111  0000
        13f8  0121  0000  1428  0000  0023  000c  0012  0000  0073  0038  6100
        0055  0007  0023  000b  0200  0000  0304  ffff  fffc  0700  0000  1d00
        1300  1200  0000  d000  386d  7973  7472  7563  7400  00b6  0000  0008
        0000  001e  000d  0012  0000  00ae  0038  6200  0055  0007  0023  0006
        0400  0000  0007  0000  001e  000d  0012  0000  00cc  0038  6300  0055
        0007  0023  0006  0400  0000  0407  0000  0004  0000  0027  000c  0012
        0000  00f7  0038  666f  6f00  0072  0000  0073  0023  000b  0200  0000
        0304  ffff  fff4  0700  0000  0400  0000  0400  0000  0500
                                                    ^^^^^^^^^^^^^^
                                     legitimate padding DIE inserted by pcc
$

fileB :

$ dump -s -n .debug fileB

new.test:

.debug:
        0000  002d  0011  0012  0000  0104  0038  7465  7374  2e63  0001  3600
        0000  0101  1100  0013  f001  2100  0014  2801  0600  0000  0000  0000
        2300  0600  1200  0000  fb00  386d  6169  6e00  0055  0007  0111  0000
        13f8  0121  0000  1428  0000  0023  000c  0012  0000  0073  0038  6100
        0055  0007  0023  000b  0200  0000  0304  ffff  fffc  0700  0000  1d00
        1300  1200  0000  d000  386d  7973  7472  7563  7400  00b6  0000  0008
        0000  001e  000d  0012  0000  00ae  0038  6200  0055  0007  0023  0006
        0400  0000  0007  0000  001e  000d  0012  0000  00cc  0038  6300  0055
        0007  0023  0006  0400  0000  0407  0000  0004  0000  0027  000c  0012
        0000  00f7  0038  666f  6f00  0072  0000  0073  0023  000b  0200  0000
        0304  ffff  fff4  0700  0000  0400  0000  0400  
                                                    ^^
                                                Zeros now fill
                                                Is this even legal
                                                don't all DIEs have
                                                to have a 4byte length AT
                                                LEAST ????

$

As you can see, the ELF library THREW away the last padding DIE. Yes, yes,
I *DID* see what I was passing to elf_newdata before I called it and
it truly did have the 0000 0005 00 padding DIE.   However after I exited the
copy program, I noticed that the 4 bytes of the last padding DIE were
gone. My d_size field included the last DIE, so why does elf_newdata
feel it can merrily toss away my data? Of course, the fact that this happens
makes the sibling of the source_file DIE wrong and life quickly degrades...
Am I going mad ?  Is there something hilariously obvious that I
am missing entirely?!?  

Boiled_down_question:  Does the ELF access library have the authority to throw
away anything that you consider to be "data" such as padding DIEs at the
end of a section? How is one suuposed to handle the trailing padding
DIEs that pcc puts out????

Please send any comments/flames/brickbats to me directly

Many thanks
Farooq

--
Standard High-Tech Disclaimer: NOTHING  in the above article has the slightest
relationship to reality. If any reality correspondences are found, please
notify me IMMEDIATELY. Any threats, abuse or stupidity of any kind is purely
UNintentional. These are MY Opinions NOT my employer's.

 
 
 

SVR4 ELF access library question... (ELF-specific)

Post by Farooq Bu » Mon, 04 Nov 1991 01:02:40


Sigh.... minutes after posting my plea for aid, (as usual) I finally
figured out what the heck waa going on.  There is data-structure
of type Elf_Data that I was setting up incorrectly for the output
file.  This caused padding information to be thrown away at the end
of a file.  Now why won't this computer do what I *mean* not what
I *say* ?!? :-)

Moral: when dealing with the SVR4 ELF access library, set up all data
verrrry correctly in the controlling data structure or suffer the
fires o' hell!

fmb
--
Standard High-Tech Disclaimer: NOTHING  in the above article has the slightest
relationship to reality. If any reality correspondences are found, please
notify me IMMEDIATELY. Any threats, abuse or stupidity of any kind is purely
UNintentional. These are MY Opinions NOT my employer's.

 
 
 

1. Can ELF programs load non-ELF libraries?

The light may finally be dawning.

I've been having perplexing difficulties with certain packages (fvwm, and now
tk) that "cannot load libfoo.so.N", and I've noted that others have similar
problems.  I got to reading the ELF-Howto last night, and finally began to
wonder why there are now two DLL loaders.  Does each *exclusively* load one
type of DLL?  Do I have to have each library in both forms, if I have both
kinds of programs on my system?  I haven't found any document that clearly
confirms or denies this.

(Other bizarre symptoms include ldd's insistence that libraries which are
present, in directories named in ld.so.conf, "could not be found".  If I drop a
symlink into /lib then the complaint changes to "not an ELF library".  This is
in the case of precompiled wish (ELF) which is attempting to load precompiled
XFree86 3.11 libX11 (non-ELF).)
--


You are in a twisty little maze of hyperlinks, all useless.

2. how do I protect my files from being linked to other sites?

3. Linux ELF: is there a SVR4 libelf.a lookalike library ?

4. wu-ftp error

5. Linux XFree86 elf xerver wn't work (Mach32, ELF)

6. Who says Linux is stable?

7. ELF Linux Distribution on CD-ROM - 100% ELF

8. version control

9. X86 Solaris ELF compatibility with Linux ELF

10. ELF system - non-ELF program

11. ELF upgrade problems -- ncurses, gdbm, elf kernel

12. Do I have ELF, Intel ELF, pcthreads or what??

13. ELF interpreter ld-elf.so.1 not found????!!