public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: binutils@sourceware.org
Subject: Re: [Bug] DWARF-5 section names in PE/PEP and weak symbols
Date: Tue, 15 Feb 2022 18:58:30 +0100	[thread overview]
Message-ID: <87bkz8hv09.fsf@Rainer.invalid> (raw)
In-Reply-To: <87y22d7lss.fsf@Otto.invalid> (ASSI's message of "Mon, 14 Feb 2022 12:02:59 +0100")


So here's another attempt at getting to the bottom of this.  The failing
gnulib test was using fputs, the actually failing gnulib module was
calling thrd_exit if the weak symbol resolved non-NULL and
serendipitously I've stumbled upon snprintf behaving differently…

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
#include <pthread.h>
#include <threads.h>
#pragma weak fputs
#pragma weak thrd_exit
#pragma weak snprintf
#pragma weak asnprintf
#pragma weak vsnprintf
int main ()
{
  char buf[256] = "snprintf was not called.\n";
  printf( "snprintf  => %014p\tis %sequal NULL\n", snprintf,  ((snprintf  == NULL) ? "" : "not ") );
  printf( "fputs     => %014p\tis %sequal NULL\n", fputs,     ((fputs     == NULL) ? "" : "not ") );
  printf( "thrd_exit => %014p\tis %sequal NULL\n", thrd_exit, ((thrd_exit == NULL) ? "" : "not ") );
  if (snprintf != NULL)
    snprintf(buf, sizeof(buf), "%s\n", "sprintf called through symbol");
  printf( "%s", buf );
  return (fputs == NULL);
}
--8<---------------cut here---------------end--------------->8---

This is what happens:

--8<---------------cut here---------------start------------->8---
...packages/binutils-gdb/build (2130)# gcc -Wl,--trace-symbol={fputs,snprintf,thrd_exit} -c -o weak_test.o weak_test.c
...packages/binutils-gdb/build (2131)# gcc -Wl,--trace-symbol={fputs,{a,v,}snprintf,thrd_exit} -o weak_test weak_test.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: weak_test.o: reference to snprintf
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: weak_test.o: reference to thrd_exit
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: weak_test.o: reference to fputs
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libcygwin.a(t-d000578.o): definition of fputs
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../lib/libcygwin.a(t-d001527.o): definition of thrd_exit
...packages/binutils-gdb/build (2132)# ./weak_test ; echo $?
snprintf  => 0x000000000000     is equal NULL
fputs     => 0x0001004012e0     is not equal NULL
thrd_exit => 0x000100401300     is not equal NULL
snprintf was not called.
0
...packages/binutils-gdb/build (2133)# nm weak_test.o /bin/cygwin1.dll | egrep ' (fputs|[av]?snprintf|thrd_exit)$'
                 U fputs
                 w snprintf
                 U thrd_exit
00000001801abb10 T asnprintf
00000001801b1610 T fputs
00000001801c0380 T snprintf
00000001801849a0 T thrd_exit
00000001801eec30 T vsnprintf
--8<---------------cut here---------------end--------------->8---

So, snprintf seems to behave as expected (it resolves NULL) and the two
other symbols are resolved even though they should not.  If they had
resolved to the actual address things might even work, but the actual
values explain nicely why a program calling through the pointer crashes
in various horrible ways (depending on what actually is mapped there).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

  reply	other threads:[~2022-02-15 17:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 18:27 Achim Gratz
2021-12-15 13:12 ` Nick Clifton
2021-12-20 19:45   ` Achim Gratz
2022-01-23  8:10     ` Achim Gratz
2022-01-29  7:57   ` Achim Gratz
2022-02-13 20:17   ` Achim Gratz
2022-02-14 11:02     ` ASSI
2022-02-15 17:58       ` Achim Gratz [this message]
2022-02-15 19:08         ` Achim Gratz
2022-02-15 20:19         ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkz8hv09.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).