Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Florian Weimer via Gcc-bugs]

* Puneet Kumar Yatnal via Gcc-bugs:

> What is next step here? How do I post this in Bugzilla and get
> support.

This issue has already been fixed with this commit:

commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely 
Date:   Tue Nov 9 23:45:36 2021 +

libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

Since Glibc 2.34 all pthreads symbols are defined directly in libc not
libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
avoid unnecessary locking in single-threaded programs. This means there
is no reason to avoid linking to libpthread now, and so no reason to use
weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

libstdc++-v3/ChangeLog:

PR libstdc++/100748
PR libstdc++/103133
* config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
Define for glibc 2.34 and later.

It's been backported to GCC 10, but not GCC 9.  Backporting to 9
requires some messaging to get into 9 which lacks commit
b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
__gthread_self weak symbol [PR 95989]").

Thanks,
Florian

Re: Investigating a stack state mismatch in Linux kernel

[Florian Weimer]

* Alexander Popov:

> Of course, there is a naive solution for this issue -- just skip stackleak
> instrumentation for acpi_duplicate_processor_id(). But it would be great to 
> find
> out the reasons behind this compiler behavior. It might help to create a 
> better
> solution.

Please show us the RTL dumps with both compilers, both before and after
the plugin pass.

Thanks,
Florian

Re: gdb doesn't get argc right

[Florian Weimer]

* Don Viszneki:

> I'm using standard Ubuntu releases of gcc (5.4.0) and gdb (7.11.1) and I
> have a very simple to reproduce issue on x86-64.
>
> I think I've included all the necessary information in this paste:
>
> https://gist.github.com/hdon/3f96a8a6b67e078e0213660ec6245677

This is likely a limitation of the debugging information format you
requested, which cannot represent some of the optimizations GCC
performed on the object code.

(I'm not sure how many people read the gcc-bugs mailing list.  It's
usually used to distribute notifications from Bugzilla, the bug
tracking tool.)

Re: libiberty sha1.c: bug in adding 64-bit number to 64-bit number (binutils-2.22.90)

[Florian Weimer]

On 09/18/2012 02:13 AM, Geoff Pike wrote:

Hello libiberty experts,

I don't see anything saying that sha1_process_block() has a size limit
on its input buffer, and if the length of the buffer is big (e.g.,
2^32 on a 64-bit machine) then this code won't correctly add a 64-bit
number to 64-bit number:

   /* First increment the byte count.  RFC 1321 specifies the possible
  length of the file up to 2^64 bits.  Here we only compute the
  number of bytes.  Do a double word increment.  */
   ctx-total[0] += len;
   if (ctx-total[0]  len)
 ++ctx-total[1];

The above is at sha1.c around line 302.


I'm not sure if many people read the gcc-bugs list, it's mainly fed from 
Bugzilla.  Better file a bug.


After a quick look at the code, I'm wondering if the ~63 is properly 
sign-extended and then converted to size_t:


  sha1_process_block (buffer, len  ~63, ctx);

This should work, but it looks a bit fishy.

--
Florian Weimer / Red Hat Product Security Team