This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Binutils objcopy bug (was Re: rebase segfault)

On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote:
> On 1/25/2013 4:00 PM, Corinna Vinschen wrote:
>> On Jan 25 14:19, Kai Tietz wrote:
>>> 2013/1/25 marco atzeri <>:
>>>> On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
>>>>> I already explained why:  The SEGV happens during relocation.
>>>>> The file header has been changed already.  If you call the
>>>>> same rebase, it will try to rebase the file to the same new
>>>>> address.  If current file base address == requested file base
>>>>> address, rebase will return without performing any action.
>>>> Hi Corinna,
>>>> I would like your opinion on this .reloc strange issue of
>>>> dict_snowball, as I have the impression I found the root cause.
>>>> [...]
>>>> Questions:
>>>> - Is it anomalous to have a .reloc portion addressing the
>>>> debug_* sections (so the original build file is broken)
>>>> - or should strip recognize and remove reloc portion not
>>>> anymore relevant ?
>>>> rebase is choking on this portion of the .reloc table
>>>>> Corinna
>>>> Thansk in advance
>>>> Marco
>>> Well, here are my 2-cents about that issue.  In general it is a flaw
>>> to have an base-relocation in debug-section, as this means such a
>>> section can't be moved into a separate debug-file anymore, due that
>>> has no relocation-information.
>>> Nevertheless it would be good, if objcopy gets adjusted to eliminated
>>> base-relocations of stripped sections.
>> But the tool generating these debug relocs is gas, isn't it?  Why
>> on earth does it do that?!?
>> I still think rebase is not to blame here.  It has to assume that
>> the relocation info is correct, doesn't it?
> rebase is not to blame. I agree ;-)
> Someone else is incorrectly managing the reloc table,
> and also objcopy seems innocent ...
> Postgresql dll's are built in this way:

My strong guess is dllwrap.
No other packages uses the ancient dllwrap anymore.
I tried to get rid of it, but got stuck somewhere else.

> gcc -ggdb -O2 -pipe
> -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/build=/usr/src/debug/postgresql-9.2.2-1
> -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2=/usr/src/debug/postgresql-9.2.2-1
> -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Wendif-labels -Wmissing-format-attribute -Wformat-security
> -fno-strict-aliasing -fwrapv -fexcess-precision=standard
> -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball
> -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball/libstemmer
> -I../../../src/include
> -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include
> -c -o dict_snowball.o
> /pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/backend/snowball/dict_snowball.c
> dllwrap -o dict_snowball.dll --dllname dict_snowball.dll  --def
> libdict_snowballdll.def dict_snowball.o api.o utilities.o
> stem_ISO_8859_1_danish.o  stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o
> stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o  stem_ISO_8859_1_german.o
> stem_ISO_8859_1_hungarian.o  stem_ISO_8859_1_italian.o
> stem_ISO_8859_1_norwegian.o  stem_ISO_8859_1_porter.o
> stem_ISO_8859_1_portuguese.o  stem_ISO_8859_1_spanish.o
> stem_ISO_8859_1_swedish.o  stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o
> stem_UTF_8_danish.o  stem_UTF_8_dutch.o stem_UTF_8_english.o
> stem_UTF_8_finnish.o  stem_UTF_8_french.o stem_UTF_8_german.o
> stem_UTF_8_hungarian.o  stem_UTF_8_italian.o stem_UTF_8_norwegian.o
> stem_UTF_8_porter.o  stem_UTF_8_portuguese.o stem_UTF_8_romanian.o
> stem_UTF_8_russian.o  stem_UTF_8_spanish.o stem_UTF_8_swedish.o
> stem_UTF_8_turkish.o -L../../../src/port -Wl,--allow-multiple-definition
> -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed
> -L../../../src/backend -lpostgres

Reini Urban

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]