tech-pkg archive

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

Re: [FOUND] String offset errors on evbarm 8.99 [PR 54159]



On Mon, Aug 05, 2019 at 06:44:11PM +0200, tlaronde wrote:
> On Mon, Aug 05, 2019 at 06:29:31PM +0200, Joerg Sonnenberger wrote:
> > On Mon, Aug 05, 2019 at 05:39:31PM +0200, tlaronde%polynum.com@localhost wrote:
> > > On Mon, Aug 05, 2019 at 03:10:37PM +0200, Martin Husemann wrote:
> > > > On Mon, Aug 05, 2019 at 12:35:58PM +0200, tlaronde%polynum.com@localhost wrote:
> > > > > Linking directly there is no problem. So the question is to obtain _how_
> > > > > the linker is invoked by the pkg building.
> > > > 
> > > > Check work/.work.log ?
> > > 
> > > That was the info needed! Thanks! (I added too PKG_LEVEL_DEBUG=2 
> > > suggested by Greg Troxel).
> > > 
> > > The offending option is this:
> > > 
> > >         -Wl,-retain-symbols-file -Wl,.libs/libp11-kit.exp
> > > 
> > > ditto: it discards every symbol that is not in this file!
> > > 
> > > So question: why is there such a thing when debug is asked for? To
> > > "just" debug the library without its interactions with the dshared libs
> > > it's linked to?
> > 
> > Can you try adding $a, $t, $t.x and $d to that list and see if that
> > fixes the problem?
> 
> No. This adds the name of the *.o files, but not some *.c present in 
> the full table and none of the symbols (functions) exported but not in
> the list.

Addition: and obviously this doesn't solve the problem of the symbols
having an index that passes the size of the table. ld still complains.

If there is a bug in the linker, it is because it should put a "?"
string in the strtab and give this offset of this string to every
symbol that is not "exported" (in the sense of the option above).

But this is totally ELF <-> BFD dependant but not MD, so I fail to see
why we stumble on the problem with armv7 and not with other machines
(unless debugging have been added for some packages specifically for
armv7?)...  (the source of the problem being that BFD doesn't handle
enough abstractions to cover the ELF usage so there are gaps---objdump(1)
vs readelf(1) is the example---so to solve the issue one needs to
know not only what is needed for ELF relocation entries but also
how it interfers with BFD; BFD is definitively not the attractive
part.)

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Home | Main Index | Thread Index | Old Index