https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #10 from Stas Sergeev ---
Hmm, seems it has --libs-only-l and --libs-only-other,
so that works too.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #9 from Stas Sergeev ---
To clarify: I used to do
LDFLAGS=`pkg-config --libs`
because I though LDFLAGS supports
both things. `pkg-config --libs`
gives lots of ldflags, plus -lXX stuff.
If we are to split this, it would
be good if p
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #8 from Stas Sergeev ---
Thanks, that seems to work.
Unfortunately pkg-config doesn't
have `--ldflags`, which is why
I haven't done that initially.
This is minor and can be ignored,
but maybe you have the plans to
add --ldflags to
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #6 from Stas Sergeev ---
So in my case I am providing (via LDFLAGS)
a lib with an alternate implementation
of the function checked with AC_CHECK_FUNC.
This works with ld.lld, but fails with
GNU ld, as configure then can't link it
(
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #5 from Stas Sergeev ---
The problem is not in a makefile,
but in autotools itself. Consider
this example performed on a plain
"ncurses" source tree:
LDFLAGS="-Wl,--as-needed -lgcc" ./configure
configure passes because -lgcc
is
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #3 from Stas Sergeev ---
Maybe gcc, when compiling directly
from .c file, should put the intermediate
object at the beginning of the linker cmdline?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=32950
--- Comment #2 from Stas Sergeev ---
But I can't even change the link
order: configure puts LDFLAGS before
conftest.c, so all configure tests
start to fail when --as-needed is
added to LDFLAGS.
What would you suggest as a fix then?
--
You a
Assignee: unassigned at sourceware dot org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 16077
--> https://sourceware.org/bugzilla/attachment.cgi?id=16077&action=edit
test case
Here is the fully automated
test-case, just run `make`:
c
https://sourceware.org/bugzilla/show_bug.cgi?id=32787
--- Comment #4 from Stas Sergeev ---
Thanks for the quick fix!
--
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 15993
--> https://sourceware.org/bugzilla/attachment.cgi?id=15993&action=edit
test case
Attached is a test case.
Please run test.sh:
$ ./
https://sourceware.org/bugzilla/show_bug.cgi?id=32463
--- Comment #7 from Stas Sergeev ---
(In reply to Nick Clifton from comment #6)
> Oh well, I will look into it next year ... :-}
Omg. :)
Happy New year!
This problem is not fatal for me,
it just popped up as a result of
a routine testing (as
https://sourceware.org/bugzilla/show_bug.cgi?id=32463
--- Comment #5 from Stas Sergeev ---
(In reply to Nick Clifton from comment #1)
> If you change the kernel.ld script to look like this:
>
> SECTIONS
> {
> TTT = .;
> #SHOULD_FAIL = . + .;
> . = SIZEOF_HEADERS;
> . = ALIGN(
https://sourceware.org/bugzilla/show_bug.cgi?id=32463
--- Comment #4 from Stas Sergeev ---
(In reply to Nick Clifton from comment #3)
> I think that this is probably a case where it would be very unwise to change
> the behaviour of the linker - since there are bound to be scripts that
> depend u
https://sourceware.org/bugzilla/show_bug.cgi?id=32463
--- Comment #2 from Stas Sergeev ---
Hi Nick.
I probably forgot to mention the
most important thing. If you change:
TTT = .;
_LGROUP = TTT;
into:
_LGROUP = .;
then suddenly bfg linker gives:
R _LGROUP
... same as lld.
So the bug
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
--- Comment #12 from Stas Sergeev ---
Ok, mold simply doesn't support
linker scripts. Whether or not it
supports STT_RELC is probably then
irrelevant.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
--- Comment #11 from Stas Sergeev ---
(In reply to H.J. Lu from comment #3)
> Which linker were you using? I tried, ld, lld, gold and mold. All worked.
Complete off-topic: this is the first
time I've heard of mold. Having the new
linker is e
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=32460
--- Comment #7 from Stas Sergeev ---
Created attachment 15851
--> https://sourceware.org/bugzilla/attachment.cgi?id=15851&action=edit
my libs
It is a fedora linker indeed.
--
You are receiving this mail because:
You are on the CC list for
https://sourceware.org/bugzilla/show_bug.cgi?id=32460
--- Comment #4 from Stas Sergeev ---
Created attachment 15850
--> https://sourceware.org/bugzilla/attachment.cgi?id=15850&action=edit
my ld.bfd
(In reply to H.J. Lu from comment #3)
> Which linker were you using? I tried, ld, lld, gold and
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=32461
--- Comment #6 from Stas Sergeev ---
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
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 #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.
--
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
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
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
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
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 #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
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 .
: 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=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
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 #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 #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
Stas Sergeev changed:
What|Removed |Added
Attachment #15232|0 |1
is obsolete|
: 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=30970
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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
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=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.
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=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=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 #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 #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.
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=30970
Stas Sergeev changed:
What|Removed |Added
CC||nickc at redhat dot com
--
You are re
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||hpa at zytor dot com
--
You are recei
https://sourceware.org/bugzilla/show_bug.cgi?id=30970
Stas Sergeev changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
You are
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=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.
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 #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
: 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=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
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=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
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
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=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
--- 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 #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
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=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
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=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=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
: 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
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
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
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
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 #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
--- 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=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=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=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.
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=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
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
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=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=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 #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
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
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
: 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
: 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.
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
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_
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 #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.
1 - 100 of 118 matches
Mail list logo
