Control: reassign 790556 binutils
Control: reassign -1 binutils
Control: forcemerge -1 790556
Control: retitle -1 LTO and gold linker broken on sparc
Am 08.09.2015 um 17:25 schrieb Artyom Tarasenko:
> On Sun, Aug 30, 2015 at 3:29 PM, Michael Biebl wrote:
>> control: user -1 debian-sp...@lists.de
On Sun, Aug 30, 2015 at 3:29 PM, Michael Biebl wrote:
> control: user -1 debian-sp...@lists.debian.org
> control: usertag -1 sparc
> control: tags -1 + help
>
> On Tue, 30 Jun 2015 11:04:20 +0300 Meelis Roos wrote:
>> Package: udev
>> Version: 221-1
>> Severity: critical
>> Justification: breaks
control: user -1 debian-sp...@lists.debian.org
control: usertag -1 sparc
control: tags -1 + help
On Tue, 30 Jun 2015 11:04:20 +0300 Meelis Roos wrote:
> Package: udev
> Version: 221-1
> Severity: critical
> Justification: breaks the whole system
>
> udev 220-7 broke sparc boot with strange messa
Reported a binutils/gold bug for it:
https://sourceware.org/bugzilla/show_bug.cgi?id=18855
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Mon, 2015-08-17 at 18:34 +0200, Artyom Tarasenko wrote:
> On Mon, Aug 10, 2015 at 9:33 AM, Frans van Berckel <
> fberc...@xs4all.nl> wrote:
>
> Checked with binutils_2.25.1-1_sparc64.deb . -Wl,-fuse-ld=gold still
> produces broken binaries.
>
> Tried manually compiling a couple of systemd bin
On Mon, Aug 10, 2015 at 9:33 AM, Frans van Berckel wrote:
> On Fri, 2015-08-07 at 20:48 +0200, Frans van Berckel wrote:
>> On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote:
>> > After 10 hours of building (my machine is probably not the fastest
>> > one),
>> > I can only confirm that the
On Fri, 2015-08-07 at 20:48 +0200, Frans van Berckel wrote:
> On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote:
> > After 10 hours of building (my machine is probably not the fastest
> > one),
> > I can only confirm that the gold linker is still broken in
> > binutils_2.25-11_sparc64.deb
On Fri, 2015-08-07 at 18:24 +0200, Artyom Tarasenko wrote:
> After 10 hours of building (my machine is probably not the fastest
> one),
> I can only confirm that the gold linker is still broken in
> binutils_2.25-11_sparc64.deb
Am I right, there are some fails / test error's, building binutils_2.
After 10 hours of building (my machine is probably not the fastest one),
I can only confirm that the gold linker is still broken in
binutils_2.25-11_sparc64.deb
Also I added
ifneq ($(findstring $(DEB_BUILD_ARCH), sparc),)
LD=ld
endif
to debian/rules (that's the only part of the patch reference
On 06/08/2015 12:48, Artyom Tarasenko wrote:
> Here is the correspondinf part of the gdb session with symbols from
> systemd-dbg_224-1_sparc64.deb:
>
Many thanks.
The log below pretty much does confirm that it is taking the suspected
path through the code. Some steps are not visible to the debug
Richard Mortimer writes:
> So maybe the code is trying to use the wrong string as input to chdir
> and hence failing.
Is udev using the gold linker during build? I've been looking into a bug
where in certain circumstances, when linking with gold, string literal
function arguments are corrupted.
Am 06.08.2015 um 16:13 schrieb d...@mattli.us:
> Richard Mortimer writes:
>
>> So maybe the code is trying to use the wrong string as input to chdir
>> and hence failing.
>
> Is udev using the gold linker during build?
It is, indeed.
We had a hack in debian/rules for a while, to use ld.bfd on
On Thu, 2015-08-06 at 16:57 +0200, Michael Biebl wrote:
> Looks like this should be fixed in binutils for good instead of
> having individual packages work around that.
They are active changing the sources in git the past months. Searching
for Sparc. Question, Is the bug stil there?
https://sou
And here is an attempt to debug why parse_proc_cmdline fails:
Breakpoint 3, main (argc=, argv=0x7fefc98) at
../src/udev/udevd.c:1662
1662r = parse_proc_cmdline(parse_proc_cmdline_item);
(gdb) step
parse_proc_cmdline (parse_item=0x1011180
) at ../src/basic/util.c:4832
4832
Here is the correspondinf part of the gdb session with symbols from
systemd-dbg_224-1_sparc64.deb:
(gdb) run
Starting program: /lib/systemd/systemd-udevd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Breakpoint 3, main (
It looks like stdout and/or stderr output is mixed up with the strace
output but it looks udevd is failing because the chdir to / fails.
Notes inline below. (Caution I'm comparing against current systemd git
HEAD and not any specific version)
http://cgit.freedesktop.org/systemd/systemd/tree/src/u
That's what I see in the strace log:
set_tid_address(0xf80100133790) = 9184
set_robust_list(0xf801001337a0, 24) = 0
rt_sigaction(SIGRTMIN, {0xf801006c6da0, [], SA_SIGINFO}, NULL,
0xf801006d2098, 8) = 0
rt_sigaction(SIGRT_1, {0xf801006c6c40, [], SA_RESTART|SA_SIGINFO},
NULL
Am 30.06.2015 um 10:04 schrieb Meelis Roos:
> Package: udev
> Version: 221-1
> Severity: critical
> Justification: breaks the whole system
>
> udev 220-7 broke sparc boot with strange messages about different
> options of udevadm not supported (--cleanup-db un recognized,
> --action=add not recogn
It appears snapshot.debian.org only has udev 215-8, 218-1, 218-2, 218-8,
220-6, 220-7, 221-1 for sparc.
with systemd 215-8:
218-2: udev OK
218-8: udev OK
220-6 fails the same 220-7 and 221-1
--
Meelis Roos (mr...@linux.ee)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian
Michael Biebl writes:
> If 215-8 was working successfully, finding the faulty commit would
> indeed be very helpful. If you know how to use git bisect, you could use
> that to determine the commit. This will be a lengthy process though and
> probably not something you want to do on a live system.
> Unfortunately snapshots.debian.org [1] doesn't seem to have any sparc64
> binaries which would have simplified that process somewhat, as you could
> have quickly installed older versions. And we don't have any sparc64
> porter boxes :-/
But it is normal sparc debian, just sparc64 kernel. Got the
Hi,
Am 30.06.2015 um 21:48 schrieb Meelis Roos:
>> Did older udev versions work?
>
> Yes.
>
> By dpkg.log, 215-18 was the previous version before 220-7 that broke.
> Unfortunatley, 215 does not seem to be available from Debian mirrors any
> more. 215-18 seems to be available from snapshot.debi
> > Upgraded to 221-1 with init=/bin/bash and chroot, still the same:
> >
> > Loading, please wait...
> > e or neveruudevadm: unrecognized option '--action=add'
>
> Is that "e or neveru" a corruption of some sort?
Yes, it seems so. With different kernel with no initramfs, there were
more corrup
Control: found -1 220-7
Control: severity -1 important
(downgrading, not a release architecture)
Am 30.06.2015 um 10:04 schrieb Meelis Roos:
> Package: udev
> Version: 221-1
> Severity: critical
> Justification: breaks the whole system
>
> udev 220-7 broke sparc boot with strange messages about
Package: udev
Version: 221-1
Severity: critical
Justification: breaks the whole system
udev 220-7 broke sparc boot with strange messages about different
options of udevadm not supported (--cleanup-db un recognized,
--action=add not recognized, --timeout=10 not recognized).
Upgraded to 221-1 with
25 matches
Mail list logo
