https://sourceware.org/bugzilla/show_bug.cgi?id=14187
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://sourceware.org/bugzilla/show_bug.cgi?id=14187
--- Comment #5 from Stas Sergeev ---
(In reply to Cary Coutant from comment #3)
> The bottom line is that I don't have a good idea for how to fix this to
> match the Gnu ld documentation without breaking something.
You had to add an option for
https://sourceware.org/bugzilla/show_bug.cgi?id=14187
--- Comment #7 from Stas Sergeev ---
(In reply to Ian Lance Taylor from comment #6)
> The difference in -Ttext behaviour between gold and GNU ld is intentional.
> The -Ttext option in GNU ld is nearly meaningless when using ELF. Gold's
> -Tt
https://sourceware.org/bugzilla/show_bug.cgi?id=14187
--- Comment #13 from Stas Sergeev ---
(In reply to Cary Coutant from comment #11)
> Created attachment 8557 [details]
> Patch to fix gold to parse -Ttext, etc., options as hex numbers
> The attached patch changes gold to parse the -Ttext, etc.
https://sourceware.org/bugzilla/show_bug.cgi?id=14187
--- Comment #15 from Stas Sergeev ---
(In reply to Cary Coutant from comment #14)
> I don't see why we should leave this bug unfixed just because we don't match
> Gnu ld's behavior for -Ttext.
>
> The original report was about accepting hex n
https://sourceware.org/bugzilla/show_bug.cgi?id=14187
--- Comment #16 from Stas Sergeev ---
(In reply to Cary Coutant from comment #14)
> The original report was about accepting hex numbers without the 0x, and had
> nothing to do with what you're talking about.
Note that the original report was e
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 14439
--> https://sourceware.org/bugzilla/attachment.cgi?id=14439&action=edit
test case
Attached is an automated test-case.
Run test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #4 from Stas Sergeev ---
Thanks, that was quick!
Interestingly, the symbol was not really excluded.
It was still present in an nm output, but without
a name.
This makes me wonder, now, in case of a non-relocatable
link when such sy
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #6 from Stas Sergeev ---
Yeah that code looks strange, and if
I had to guess (w/o ever looking into
the actual code), I'd say that just
this is enough:
if (name == NULL || *name == '\0')
disable_output_symbol_name();
as i
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 14462
--> https://sourceware.org/bugzilla/attachment.cgi?id=14462&action=edit
test case
Attached is a test-case.
Shell script runs
ld -mi386pe crt0.o lib
https://sourceware.org/bugzilla/show_bug.cgi?id=29807
--- Comment #1 from Stas Sergeev ---
JFYI, I have created that object
with objcopy from elf. Not sure
what is fuzzed.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29807
--- Comment #3 from Stas Sergeev ---
Created attachment 14464
--> https://sourceware.org/bugzilla/attachment.cgi?id=14464&action=edit
elf test-case
Here is the original objects which I
converted to PE.
Without conversion to PE, the link
suc
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #7 from Stas Sergeev ---
Created attachment 14465
--> https://sourceware.org/bugzilla/attachment.cgi?id=14465&action=edit
new test-case
Here is a new test-case that shows
the symbol name drop even w/o
relocatable linking.
Please
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #8 from Stas Sergeev ---
Please run `nm a.out | grep 2000`
after test.sh.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29807
--- Comment #4 from Stas Sergeev ---
Created attachment 14466
--> https://sourceware.org/bugzilla/attachment.cgi?id=14466&action=edit
reduced test-case
I reduced the test-case to bare minimum.
No fancy binary blobs this time!
Just run "make
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://sourceware.org/bugzilla/show_bug.cgi?id=29807
--- Comment #5 from Stas Sergeev ---
I suggest removing "fuzzed" from
the description as it suggests I
did something malicious to the objects.
Last test-case shows I didn't, as
it generates an objects from source.
--
You are receiving this m
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
void foo(void);
int main()
{
foo();
return 0;
}
$ gcc -shared -Wl,--no-allow-shlib-undefined -o libmain.so main.c
produces no error.
Things like
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 14467
--> https://sourceware.org/bugzilla/attachment.cgi?id=14467&action=edit
test case
Attached is a simple test-case
: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 14468
--> https://sourceware.org/bugzilla/attachment.cgi?id=14468&action=edit
test case
Attached test-case shows that the
program
https://sourceware.org/bugzilla/show_bug.cgi?id=29809
--- Comment #2 from Stas Sergeev ---
(In reply to Alan Modra from comment #1)
> Don't strip relocatable object files if you
> need access to their symbols!
Are the resulting objects useful for anything at all?
Is the intentional behavior docu
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #11 from Stas Sergeev ---
(In reply to H.J. Lu from comment #10)
> Linker removed the local symbol _CRT0_EH_FRAME_BEGIN_ since its section,
> .eh_frame,
> was unused and removed.
But why it only removed the name
of a symbol? Can i
https://sourceware.org/bugzilla/show_bug.cgi?id=29761
--- Comment #14 from Stas Sergeev ---
Thanks, so with this fix I suppose
the symbol in the last test-case no
longer loses its name.
But is it really removed as it should
be per comment #10?
--
You are receiving this mail because:
You are on
https://sourceware.org/bugzilla/show_bug.cgi?id=29807
--- Comment #8 from Stas Sergeev ---
If only objcopy could also be fixed...
Is there now any other way to create
PE, rather than to install mingw?
Seems like w/o working objcopy, one
needs to install mingw just for that?
--
You are receiving
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 14644
--> https://sourceware.org/bugzilla/attachment.cgi?id=14644&action=edit
test case
$ ld -melf_i386 -shared --whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=30063
--- Comment #2 from Stas Sergeev ---
Thanks!
May I guess that the fix went to the older branches as a
back-port, but wasn't initially in them?
Do you know in what version it initially went in, not as a back-port?
Or maybe you know the exact co
https://sourceware.org/bugzilla/show_bug.cgi?id=30063
--- Comment #4 from Stas Sergeev ---
Your @redhat address indicates you may well raise it to fedora? :)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30063
--- Comment #7 from Stas Sergeev ---
(In reply to H.J. Lu from comment #6)
> The input files are i386 COFF files. If the linker supports i386 COFF, you
> will
> get the undefined symbol error for i386 COFF input:
Thanks for an update.
But I
https://sourceware.org/bugzilla/show_bug.cgi?id=30063
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|NOTABUG
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #5 from Stas Sergeev ---
Created attachment 14836
--> https://sourceware.org/bugzilla/attachment.cgi?id=14836&action=edit
test case
This test-case ends with
ld: error: source object obj2.o has EABI version 5, but target out.o h
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #7 from Stas Sergeev ---
(In reply to Nick Clifton from comment #6)
> It doesn't. :-( But you can fix the problem by rearranging the order of the
> object files on the link command line:
Thanks, waiting for the test results from
https://sourceware.org/bugzilla/show_bug.cgi?id=30063
--- Comment #10 from Stas Sergeev ---
(In reply to Alan Modra from comment #9)
> No, there isn't a bug here that needs fixing. Linking input object files to
> other output formats is something that ld can do in only very limited
> circumstanc
: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
$ objcopy -I binary -O pe-x86-64 /etc/resolv.conf tst.o
$ file tst.o
tst.o: data
Same for pe-i386.
Looking into the resulting file, it
seems to contain the needed
https://sourceware.org/bugzilla/show_bug.cgi?id=30561
--- Comment #2 from Stas Sergeev ---
Hi Nick, thanks for a suggestion.
Its not as simple, at the very minimum
I'll need to generate with some script
such .S files, so that they provide the
needed symbols, like
_binary__etc_resolv_conf_start
_b
https://sourceware.org/bugzilla/show_bug.cgi?id=30561
--- Comment #4 from Stas Sergeev ---
(In reply to Nick Clifton from comment #3)
> Well for example, objcopy has no way of determining whether the input binary
> contains code, data, or something else. So it is not at all obvious which
> secti
https://sourceware.org/bugzilla/show_bug.cgi?id=30561
--- Comment #5 from Stas Sergeev ---
OK, I use the work-around you suggested.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hi guys.
I've recently discovered this binutils fork by HPA:
https://git.syslinux.org/users/hpa/segelf/binutils.git/
Which implements this elf extension pro
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
CC||hpa at zytor dot com
--
You are recei
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
CC||amodra at gmail dot com
--
You are re
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
CC||nickc at redhat dot com
--
You are re
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15176
--> https://sourceware.org/bugzilla/attachment.cgi?id=15176&action=edit
test case
Please run ./test.sh from the attached archive.
It uses -
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #9 from Stas Sergeev ---
The status of this bug is "WAITING".
Waiting for what?
I provided a test-case and it was
confirmed, so please update the status?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #11 from Stas Sergeev ---
(In reply to Nick Clifton from comment #10)
> The results of the tests that you said you were running in comment #7.
The results were absolutely positive.
The suggested work-around works as expected.
But
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #13 from Stas Sergeev ---
(In reply to cvs-com...@gcc.gnu.org from comment #12)
> The master branch has been updated by Nick Clifton :
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=a79e9a07a0d350031cd491031a756
https://sourceware.org/bugzilla/show_bug.cgi?id=28910
--- Comment #17 from Stas Sergeev ---
(In reply to Nick Clifton from comment #16)
> Stas - if you can find a way to trigger the bug with these patches applied,
> please feel free to reopen this PR.
I tried to reproduce it again
(w/o any patch
https://sourceware.org/bugzilla/show_bug.cgi?id=30974
--- Comment #1 from Stas Sergeev ---
(In reply to Stas Sergeev from comment #0)
> It would really help if you implement ASSERT()
> natively, but this is another story.
Except that ASSERT() is already there. :)
I made sure that with ASSERT() t
https://sourceware.org/bugzilla/show_bug.cgi?id=30974
--- Comment #3 from Stas Sergeev ---
You need to consider being compatible
with lld, which disagree with what you
say.
But that suggestion works for me, thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15182
--> https://sourceware.org/bugzilla/attachment.cgi?id=15182&action=edit
test case
Please unpack the attached test-case and
run "ma
https://sourceware.org/bugzilla/show_bug.cgi?id=30984
--- Comment #1 from Stas Sergeev ---
The test-case basically just creates the
absolute section:
.intel_syntax noprefix
.section .text
.code32
.global main
;.extern printf
main:
mov eax, 0xDEADBEEF
push eax
push message
; call printf
https://sourceware.org/bugzilla/show_bug.cgi?id=30984
--- Comment #5 from Stas Sergeev ---
Thank you.
Could you please hint me how
to create an absolute symbol?
I already know that if I do
symbol = ABSOLUTE(.);
in a linker script, then there
will be no dynamic relocs against
this symbol. I wanted
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
--- Comment #1 from Stas Sergeev ---
It turned out R_RELC can be used
instead of the custom reloc schemes.
So that HPA work can be reduced to
just this patch:
diff --git a/gas/config/tc-i386.h b/gas/config/tc-i386.h
index 80d66c1ce15..7b036a7
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15232
--> https://sourceware.org/bugzilla/attachment.cgi?id=15232&action=edit
test case
Attached is a test-case.
It is an elf file f
https://sourceware.org/bugzilla/show_bug.cgi?id=31106
Stas Sergeev changed:
What|Removed |Added
Attachment #15232|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=31106
--- Comment #3 from Stas Sergeev ---
(In reply to Nick Clifton from comment #1)
> Is it possible that you uploaded the stripped file ?
Thank you.
I have re-uploaded the file now
(haven't checked if the first one
was alredy stripped, but likel
https://sourceware.org/bugzilla/show_bug.cgi?id=31106
--- Comment #6 from Stas Sergeev ---
(In reply to Nick Clifton from comment #4)
> (Incidentally the symbols have very strange
> looking names. Is this deliberate ?)
This is a so-called "RELC encoding".
I've looked into binutils source to fi
https://sourceware.org/bugzilla/show_bug.cgi?id=31106
--- Comment #8 from Stas Sergeev ---
(In reply to Nick Clifton from comment #7)
> Created attachment 15236 [details]
> Proposed patch
>
> Hi Stas,
>
> Please can you try out this patch ?
Hi, it would be easier if you just
provide the newl
https://sourceware.org/bugzilla/show_bug.cgi?id=31106
--- Comment #11 from Stas Sergeev ---
OK, I checked that the new binary
works as expected.
Thank you!
But I am really a bit disappointed
if you leave the current objcopy
behavior that can still remove relocations
at will...
Yes, I understand t
: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 11375
--> https://sourceware.org/bugzilla/attachment.cgi?id=11375&action=edit
test case
Out of sudden my prog started to randomly c
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #2 from Stas Sergeev ---
(In reply to H.J. Lu from comment #1)
> dpmi.o has:
>
> 8f69: 8b 83 00 00 00 00 mov0x0(%ebx),%eax 8f6b:
> R_386_GOT32X DPMI_return_from_realmode
> 8f6f: 66 05 00 48
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #4 from Stas Sergeev ---
(In reply to H.J. Lu from comment #3)
> do_dpmi_int has
Ah, I see now what you mean.
> 8f69: 8b 83 00 00 00 00 mov0x0(%ebx),%eax 8f6b:
> R_386_GOT32X DPMI_return_from_realmode
>
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #5 from Stas Sergeev ---
Basically this code calculates the distance
between "DPMI_return_from_realmode" and "DPMI_dummy_start",
and puts the result into a 16bit variable.
That explains the use of %ax. Its possible because
those fu
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #7 from Stas Sergeev ---
Created attachment 11379
--> https://sourceware.org/bugzilla/attachment.cgi?id=11379&action=edit
verbose asm
> Please provide pre-processed dpmi.c from gcc -E and command-line
> options to generate dpmi.
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #8 from Stas Sergeev ---
Created attachment 11381
--> https://sourceware.org/bugzilla/attachment.cgi?id=11381&action=edit
preprocessed output
--
You are receiving this mail because:
You are on the CC list for the bug.
_
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #9 from Stas Sergeev ---
(In reply to H.J. Lu from comment #6)
> Please provide pre-processed dpmi.c from gcc -E and command-line
> options to generate dpmi.s
gcc -xc -S -fverbose-asm -O -o dpmi.s dpmi.E
gcc version 7.3.0 (Ubuntu
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #12 from Stas Sergeev ---
(In reply to H.J. Lu from comment #11)
> Please add -fno-pie as workaround.
Done.
This works properly.
Thank you.
> > Btw, could you please explain why the problem
> > only happens with -export-dynamic? T
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #14 from Stas Sergeev ---
> H.J. Lu changed:
>
>What|Removed |Added
>
> Component|ld
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #16 from Stas Sergeev ---
> H.J. Lu changed:
> Please try:
>
> https://sourceware.org/ml/binutils/2018-11/msg00021.html
>
> You need to compile with the new assembler.
Building your git now...
However. Are there really no hopes
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #19 from Stas Sergeev ---
> H.J. Lu changed:
> Your code doesn't conform to i386 psABI, which doesn't
> support only using lower 16 bits of GOT entries.
I would understand if linker writes me such an error.
Silently producing corr
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #20 from Stas Sergeev ---
I disasmed and diffed the object files
without and with your patch. I see a lot of:
---
597,598c597,598
< 745: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi
< 749: 8d bc 27 00 00 0
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #23 from Stas Sergeev ---
> What your code did is outside of scope of i386 psABI.
Why not linker tells me so with an error msg?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #25 from Stas Sergeev ---
> What your code did is outside of scope of i386 psABI.
Why not linker tells me so with an error msg?(In reply to H.J. Lu from comment
#24)
> (In reply to Stas Sergeev from comment #23)
> > > What your co
https://sourceware.org/bugzilla/show_bug.cgi?id=23854
--- Comment #26 from Stas Sergeev ---
By the way, is it a feature of this
bugzilla to open the entirely different
bug ticket after I post any comment?
This always makes me worry that I posted
to wrong thread.
For example, when I post to _this_
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: stsp at users dot sourceforge.net
CC: ian at airs dot com
Target Milestone: ---
Created attachment 11492
--> https://sourceware.org/bugzilla/attachment.cgi?id=11492&action=edit
test case
: ld
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 11493
--> https://sourceware.org/bugzilla/attachment.cgi?id=11493&action=edit
test case
Attached is a test-case.
Please run test.sh.
: gold
Assignee: ccoutant at gmail dot com
Reporter: stsp at users dot sourceforge.net
CC: ian at airs dot com
Target Milestone: ---
Created attachment 12108
--> https://sourceware.org/bugzilla/attachment.cgi?id=12108&action=edit
test case
Attached is
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: stsp at users dot sourceforge.net
CC: ian at airs dot com
Target Milestone: ---
Created attachment 12109
--> https://sourceware.org/bugzilla/attachment.cgi?id=12109&action=edit
test case
The a
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
#include
int main()
{
int16_t w;
asm volatile("fist %0\n" : "=m"(w));
return 0;
}
fist.c: Assembler messages:
fist.c:6: Warning: no instruction mnemo
https://sourceware.org/bugzilla/show_bug.cgi?id=27106
--- Comment #2 from Stas Sergeev ---
Yes, I tried "fists" already and noted
it doesn't cause a warning or an error.
But:
s = single (32-bit floating point).
So why would that be what I ask for?
It doesn't look 16bit to me, or what
am I missin
https://sourceware.org/bugzilla/show_bug.cgi?id=27106
--- Comment #3 from Stas Sergeev ---
The description is from here:
https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax#Operation_Suffixes
Hope its a valid one.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27106
--- Comment #5 from Stas Sergeev ---
OK, thank you.
Would you like to fix the documentation?
Am I right that it should say:
s = single (16-bit integer or 32-bit floating point)?
--
You are receiving this mail because:
You are on the CC list
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #7 from Stas Sergeev ---
(In reply to Nick Clifton from comment #6)
> (In reply to Stas Sergeev from comment #5)
>
> > Even if it covers some "random"
> > data in a file? IMHO that's still
> > a but. If it would be zero-sized
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #5 from Stas Sergeev ---
(In reply to Nick Clifton from comment #4)
> Sure - if the segment is referencing beyond the of the file then it is a
> bug. But if not then it is more of an unexpected behaviour than a real
> fault.
Even
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #3 from Stas Sergeev ---
Thanks for such a detailed reply!
Its really helpful.
(In reply to Nick Clifton from comment #2)
> Agreed, although this is probably an enhancement rather than a bug.
Having stalled PT_LOAD segment
is mos
: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15745
--> https://sourceware.org/bugzilla/attachment.cgi?id=15745&action=edit
test-case
--
You are receiving this mail because:
You
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #1 from Stas Sergeev ---
The attached test file is needed to
reproduce the problem:
$ readelf -l tmp.elf
Section to Segment mapping:
Segment Sections...
00 .note.gnu.property
01 .text
02 .bss
03 .
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #9 from Stas Sergeev ---
(In reply to Nick Clifton from comment #8)
> OK, so the -Ttext-segment sets the start address for the text segment
> and by default the other segments (rodata & data) are mapped to start
> after the end of
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #10 from Stas Sergeev ---
Let me clarify.
So with --Trodata-segment=0x08148000 I get this:
ТипСмещ.Вирт.адр Физ.адрРзм.фйл Рзм.пм Флг Выравн
LOAD 0x00 0x08048000 0x08048000 0x0011c 0x0011c
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15843
--> https://sourceware.org/bugzilla/attachment.cgi?id=15843&action=edit
test-case
Attached is a test-case.
$ ./
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15842
--> https://sourceware.org/bugzilla/attachment.cgi?id=15842&action=edit
test-case
Attached is the test-case tha
https://sourceware.org/bugzilla/show_bug.cgi?id=32461
--- Comment #3 from Stas Sergeev ---
OK, thanks.
But what to do?
Use different opts on ld and lld?
lld says using -Ttext-segment is invalid,
and I also suspected the same, because
when I read segments with `readelf -l`,
I see that
Type
https://sourceware.org/bugzilla/show_bug.cgi?id=32461
--- Comment #4 from Stas Sergeev ---
Why not to stay compatible with
lld here? It seems to be doing the
right thing, at least in my understanding.
So while its definitely up to you,
I really suspect that closing this
ticket is sub-optimal.
--
ty: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 15841
--> https://sourceware.org/bugzilla/attachment.cgi?id=15841&acti
iority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
$ ld --image-base=0x08148000
ld: unrecognized option '--image-base=0x08148000'
Works (and produces the expected output
whe
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
--- Comment #2 from Stas Sergeev ---
Created attachment 15849
--> https://sourceware.org/bugzilla/attachment.cgi?id=15849&action=edit
new test case
No custom linker here, no!
Attached it a new test-case.
Now it links libtmp.so from
object f
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
Stas Sergeev changed:
What|Removed |Added
Resolution|FIXED |MOVED
--- Comment #10 from Stas Sergee
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
Stas Sergeev changed:
What|Removed |Added
Resolution|MOVED |FIXED
--- Comment #9 from Stas Sergeev
https://sourceware.org/bugzilla/show_bug.cgi?id=32461
--- Comment #6 from Stas Sergeev ---
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
1 - 100 of 118 matches
Mail list logo
