https://sourceware.org/bugzilla/show_bug.cgi?id=33194
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
Nick Alcock changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #10 from Nick Alco
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #8 from Nick Alcock
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
--- Comment #7 from Nick Alcock ---
... never mind, that crash doesn't happen if you use the system compiler (I was
using GCC 14 by mistake) -- I get a mass of undefined symbol errors linking
libbfd instead:
Undefined symbols for architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
--- Comment #6 from Nick Alcock ---
Presumably this was a static link? I can't make libbfd link dynamically at all
on cfarm104:
CCLD libbfd.la
0 0x1011280c0 __assert_rtn + 140
1 0x10112edb8 ld::tool::OutputFile::setFixup64(unsigned
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
--- Comment #4 from Nick Alcock ---
Hm. It's not entirely unreachable code, actually, and some things do use
it...can I make this less incomprehensible, at least... I think so.
--
You are receiving this mail because:
You are on the CC list f
||nick.alcock at oracle dot com
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Nick Alcock ---
See 33194 (which is a dupe of this, but I started looking at that first).
*** This bug has been marked as a duplicate of bug 33194 ***
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
Nick Alcock changed:
What|Removed |Added
CC||kirill at korins dot ky
--- Comment #3
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=33161
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=33194
--- Comment #2 from Nick Alcock ---
... on second thought it's hardly more difficult to simply remove the lazy
loading misfeature. On closer investigation it is entirely inaccessible from
the public API anyway: no loss.
--
You are receiving
sourceware dot org |nick.alcock at oracle
dot com
Last reconfirmed||2025-07-23
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Nick Alcock ---
This is a weak symbol reference used for lazily opening CTF in the linking API
(an extremely
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #19 from Nick Alcock ---
I'm adding a bunch more symbols: basically everything in the ABI-mandated lists
in elf_solaris2_before_allocation. None of these are C entities, any of them
might end up as STT_OBJECTs (though for most of t
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #18 from Nick Alcock ---
OK, the shell is not somewhere I had even considered as a bug source for this
(nor textual corruption in the generated emulation stuff). This has been my
official "now I feel like an idiot" moment for the d
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #16 from Nick Alcock ---
Hm. This freshly built GNU ld on the compile farm box which I believe is yours
(cfarm216) seems to be quite unhappy:
nix@s11-sparc:~/binutils-gdb/build/ld$ ./ld-new --verbose
GNU ld (GNU Binutils) 2.45.50.
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #14 from Nick Alcock ---
I think I have something which can literally check to see whether the linker is
dedupping CTF or simply concatenating it :) so even non-GNU linkers should just
skip libctf tests that require a deduplicating
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #11 from Nick Alcock ---
OK, so it's kind of acceptable to have required configurations for a GCC used
for binutils testing, then. I wasn't sure. Time to build a new GCC locally on
that cfarm box :)
(it *is* probably valuable to h
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #9 from Nick Alcock ---
OK, so this GCC was configured with
--without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as
These absolute paths force collect2 to use those paths no matter what -B says.
nix@s11-sp
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #8 from Nick Alcock ---
Yes -- but if GCC wasn't built with GNU ld, collect2 appears to run the non-GNU
ld anyway, ignoring(?) -B:
nix@s11-sparc:~/binutils-gdb/build/libctf$ LIBCTF_DEBUG=t gcc -v
-B/home/nix/binutils-gdb/build/lib
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #6 from Nick Alcock ---
... OK, so I need to detect (and probably need to detect for ld tests as well)
when gcc is built to use a non-GNU ld, and skip all tests that require CTF
dedup in this case. (Again, this probably includes a
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #5 from Nick Alcock ---
OK, the libctf failures are because it's running the wrong linker. Now, what's
up with that...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #4 from Nick Alcock ---
We can probably assume that pre-v8plus hardware is long extinct, so this
horrible hack will probably do. (A shame we can't arrange to assemble "the same
way GCC does", though.)
--
You are receiving this ma
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #2 from Nick Alcock ---
There's a big pile of libctf/ failures too, none of which I remember seeing
before... I'll have a look at those.
--
You are receiving this mail because:
You are on the CC list for the bug.
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #1 from Nick Alcock ---
I think we can safely say that the PLT will never itself be an entity with a C
type, so this patch is good. (And those symbols were basically there because of
Solaris in the first place, anyway.)
I'l
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #10 from Nick Alcock ---
Well, with that fixed the libctf tests do pass on Sol11.4. The ld tests are...
full of pain, but still better than on some platforms.
--
You are receiving this mail because:
You are on the CC list for the
at sourceware dot org |nick.alcock at oracle
dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
The failure is embarrassingly silly:
checking for linker versioning flags... -Wl,-B,local -Wl,-z,gnu-version-script
/home/nix
https://sourceware.org/bugzilla/show_bug.cgi?id=33161
Nick Alcock changed:
What|Removed |Added
Host||*-solaris2.11*
Build|
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #8 from Nick Alcock ---
That's not the only problem I found on Sol11.4... builds fail entirely when
Solaris ld is in use because the libctf-nobfd.ver script generation is broken.
I'll raise another bug.
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #5 from Nick Alcock ---
Oh of course, we already have mmap-disabling code in place! More fool me, I
only wrote it. It will also turn off (entirely working) mmapping of reads, but
since that's only used for uncompressed CTF, and nev
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #3 from Nick Alcock ---
Thank you for the report!
The advantage of the mmap dance is purely that it makes writing out the header
simpler: we can jump around in it and just treat it like a data structure
rather than messing about w
https://sourceware.org/bugzilla/show_bug.cgi?id=31611
Nick Alcock changed:
What|Removed |Added
CC||nick.alcock at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=31863
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=33047
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=31863
--- Comment #5 from Nick Alcock ---
There is a caveat here: this has to be conditionalized further unless you want
to replace an ugly warning on one platform with an ugly warning with a
different compiler on all platforms, because clang doesn'
https://sourceware.org/bugzilla/show_bug.cgi?id=33047
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
cu-mapped CTF links are a weird variant of linking which, rather than emitting
conflicting types into child
||nick.alcock at oracle dot com
--- Comment #1 from Nick Alcock ---
O. I wondered why this was happening!
Will pull this fix in. Thank you very much! (The libcs MinGW can use all seem
to support %z perfectly well, which makes this behaviour deeply confusing. I
guess GCC is
https://sourceware.org/bugzilla/show_bug.cgi?id=31863
--- Comment #3 from Nick Alcock ---
Oh it hasn't -- I see the warnings on MinGW everywhere too. I was merely noting
that this doesn't seem to align with the behaviour of the actual printf in the
various libcs MinGW can use, which all seem to s
https://sourceware.org/bugzilla/show_bug.cgi?id=30985
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32426
Nick Alcock changed:
What|Removed |Added
CC||nick.alcock at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32986
Nick Alcock changed:
What|Removed |Added
CC||nick.alcock at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32903
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=32903
--- Comment #5 from Nick Alcock ---
OK, so having added some actual tests for this, more than ctf_bufopen needs
fixing: a bunch of ctf_archive entry points do too. Fix under test (not just on
v4: against master too).
We still do not set the c
https://sourceware.org/bugzilla/show_bug.cgi?id=32903
--- Comment #4 from Nick Alcock ---
I'm piling another fix in on top of this on the v4 branch, and getting
ctf_bufopen to always set its errp to 0 on success, so it always has a defined
value after an open come what may.
--
You are receiving
https://sourceware.org/bugzilla/show_bug.cgi?id=32903
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32903
--- Comment #2 from Nick Alcock ---
Formally, we do not define what happens to the err pointer except on failure,
but I'd agree that overwriting it with junk is bad!
I agree with the fix, and will drop something like it into the CTFv4 branch
https://sourceware.org/bugzilla/show_bug.cgi?id=32746
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=32746
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #2 from Nick Alcock ---
(oops, logged in with the wrong account: taken, for the doc fix if nothing else
is needed, the full fix otherwise.)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31882
--- Comment #7 from Nick Alcock ---
Thanks, Alan. I can start using %z without fear from now on, as opposed to just
accidentally using it out of habit and then cursing and reverting it when it
breaks on mingw. (I'm fairly sure that when libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=31882
--- Comment #4 from Nick Alcock ---
This patch replaces a non-%z with a %z -- can we actually rely on %z working
these days? I used to have to use %i and casts...
--
You are receiving this mail because:
You are on the CC list for the bug.
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #1 from Nick Alcock ---
There are no uses of any of these functions in crash-inducing or error-inducing
ways in the linker or CTF deduplicator; the deduplicator never calls
ctf_add_member_encoded at all, and when it adds types to
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
This dumps core:
ctf_dict_t *fp;
ctf_encoding_t e = { CTF_INT_SIGNED, 0, sizeof (long) };
ctf_id_t type;
int err;
if ((fp
https://sourceware.org/bugzilla/show_bug.cgi?id=30226
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Nick Alcock
https://sourceware.org/bugzilla/show_bug.cgi?id=27967
Nick Alcock changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29983
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30013
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30264
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30264
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
In e.g.
struct A
{
int a;
char *b;
struct
{
struct
{
char *one;
int two;
};
};
};
offsetof (struct A
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #1 from Nick Alcock ---
Testing a fix now.
--
You are receiving this mail because:
You are on the CC list for the bug.
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
Minimal reproducer:
[ibhagat@ibhagatpc final2]$ cat t.i
# 8 ""
typedef struct
{
union
{
int addr4;
https://sourceware.org/bugzilla/show_bug.cgi?id=30013
--- Comment #3 from Nick Alcock ---
It's curious that this works in 2.39: going by the source code it should have
been broken all the way from the introduction of the deduplicator in 2.36,
since we always sorted the output mappings so that obj
https://sourceware.org/bugzilla/show_bug.cgi?id=30013
--- Comment #2 from Nick Alcock ---
Replicated. I also observe a bunch of failures in the libctf and ld/ld-ctf
testsuites, all of the form you report.
Fix under test (at first sight it appears to fix it), and I've audited all
qsort uses in li
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #1 from Nick Alcock ---
Looks like it. This is strange because the no-qsort case is *meant* to get
routinely tested... as is Solaris 11.3. But I don't often do full GCC
bootstraps on it, so I guess we can see how this got
https://sourceware.org/bugzilla/show_bug.cgi?id=29983
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
The observed failure looks like this when running the testsuite:
failed with: , expected:
FAIL
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
Nick Alcock changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
--- Comment #9 from Nick Alcock ---
On 20 Sep 2022, slyich at gmail dot com spake thusly:
> Seems to build binutils just fine! Detected `nm -p` command option.
Great! It'll go in the next tranche, and probably be backported to 2.39.
(But that
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
--- Comment #7 from Nick Alcock ---
(Sorry for delay: post-conf collapse, UK bank holiday, massive change of
monitor configuration meaning my displays were scattered all around the
room for a day, etc)
On 14 Sep 2022, slyich at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27305
--- Comment #8 from Nick Alcock ---
... any movement on this?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #5 from Nick Alcock
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
--- Comment #4 from Nick Alcock ---
Oh this gets more fun. We can't use the exit code because some nm's return a
nonzero exit code if no symbols are found! I'll have to add a grosser hack,
looking for the string 'invalid argument' (in the C lo
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
--- Comment #3 from Nick Alcock ---
Having nm be a shell wrapper should be fine (I've been testing some of the
odder edge cases that way). That's one reason we look through $PATH to find it
;)
--
You are receiving this mail because:
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=29547
Nick Alcock changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=29242
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=29242
--- Comment #3 from Nick Alcock ---
Fix will be in 2.39. (Backport to 2.38 under test.)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29242
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
We observe on Gentoo a crash when linking Mesa 22.0.3 when compiled with -gctf.
GDB reports:
Starting program: /usr/bin
https://sourceware.org/bugzilla/show_bug.cgi?id=28933
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=28933
--- Comment #5 from Nick Alcock ---
This unchecked length is only an overrun in the uncompressed-and-corrupted
foreign-endian CTF case (it's still wrong if the CTF is uncompressed but
native-endian, but it's only used at serialization time, wh
https://sourceware.org/bugzilla/show_bug.cgi?id=28933
--- Comment #4 from Nick Alcock ---
Aha! Yep, that's got it. Thank you, your object file was very helpful. Now to
fix it...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28933
--- Comment #2 from Nick Alcock ---
FWIW, I cannot replicate this: not with the x86->ppc cross shown here, nor on
ppc native, nor on ppc64. Nonetheless we should armour against this. I'll see
what I can do...
--
You are receiving this mail b
at sourceware dot org |nick.alcock at oracle
dot com
--- Comment #1 from Nick Alcock ---
Interesting! I routinely do both, so this must be a recent regression (well,
ok, as recent as a few months ago. I'll get back to libctf soon.)
This is assembler input for a corrupted CTF dict, b
https://sourceware.org/bugzilla/show_bug.cgi?id=28545
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #11 from Nick Alcoc
https://sourceware.org/bugzilla/show_bug.cgi?id=28545
Nick Alcock changed:
What|Removed |Added
CC||nick.alcock at oracle dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #25 from Nick Alcock ---
Thanks for the heads-up!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27967
--- Comment #5 from Nick Alcock ---
Mail sent out to binutils@ for review.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27967
Nick Alcock changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from Nick Alcock
https://sourceware.org/bugzilla/show_bug.cgi?id=27967
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
||nick.alcock at oracle dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #3 from Nick Alcock ---
Hm. --gnu-version-script and -z gnu-version-script appear to be recent enough
that no machines in the
||2021-06-15
Status|UNCONFIRMED |WAITING
CC||nick.alcock at oracle dot com
--- Comment #2 from Nick Alcock ---
This is probably a duplicate of bug 27360. Could you try the
users/nalcock/libctf-install-relink branch
https://sourceware.org/bugzilla/show_bug.cgi?id=25155
Nick Alcock changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=27305
--- Comment #5 from Nick Alcock ---
The Source Mage bug is probably a different problem again, and I think it's
more a Source Mage problem really. It is in general not safe to remove
toolchain binaries completely before 'make install' for prec
https://sourceware.org/bugzilla/show_bug.cgi?id=27305
--- Comment #6 from Nick Alcock ---
(... if Source Mage always removes packages before installing them, how does it
install make or coreutils? I suppose I should download it and have a look!)
--
You are receiving this mail because:
You are o
1 - 100 of 152 matches
Mail list logo
