Bug 59122 - [4.9 Regression] libsanitizer merge from upstream r191666 causes duplicate symbol errors
Summary: [4.9 Regression] libsanitizer merge from upstream r191666 causes duplicate sy...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: sanitizer (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: 4.9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-13 22:53 UTC by Peter Bergner
Modified: 2013-11-15 16:58 UTC (History)
5 users (show)

See Also:
Host:
Target: powerpc64-linux
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
untested fix (317 bytes, patch)
2013-11-13 23:10 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Bergner 2013-11-13 22:53:16 UTC
After the bootstrap issue from PR59009 was fixed, I'm now seeing other fallout from the upstream libsanitizer merge.

[bergner@igoo asan]$ cat foo.i 
extern int printf(const char *format, ...);
void
Child (void)
{
  char x[32] = {0};
  printf ("Child:  \n", x);
}

int
main (void)
{
  return 0;
}
[bergner@igoo asan]$ /home/bergner/gcc/build/gcc-fsf-mainline-asan/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-asan/gcc/ -fsanitize=address -O1 -m32 -c foo.i 
/tmp/ccadY6mS.s: Assembler messages:
/tmp/ccadY6mS.s:136: Error: symbol `.LASANPC0' is already defined

The duplicate symbol is coming from:

void
asan_function_start (void)
{
  section *fnsec = function_section (current_function_decl);
  switch_to_section (fnsec);
  ASM_OUTPUT_DEBUG_LABEL (asm_out_file, "LASANPC",
                         current_function_funcdef_no);
}

It seems current_function_funcdef_no isn't being incremented when we expected it to be.
Comment 1 Jakub Jelinek 2013-11-13 23:10:23 UTC
Created attachment 31213 [details]
untested fix

This seems to work for me in the cross, but it is a hack in any case (before and now with the patch).  What I need is some way how to represent labels emitted somewhere in the current CU, wonder what a proper way (rather than pretending it is a VAR_DECL in current CU) would be.  Can it be say a LABEL_DECL with hand set DECL_RTL, something else?
Comment 2 Peter Bergner 2013-11-14 15:29:43 UTC
(In reply to Jakub Jelinek from comment #1)
> This seems to work for me in the cross, but it is a hack in any case (before
> and now with the patch).

I'll give your patch a try, thanks.


> What I need is some way how to represent labels
> emitted somewhere in the current CU, wonder what a proper way (rather than
> pretending it is a VAR_DECL in current CU) would be.  Can it be say a
> LABEL_DECL with hand set DECL_RTL, something else?

Maybe richi has a suggestion?  I'm not familiar with this code, so I have no suggestions to give.
Comment 3 Peter Bergner 2013-11-14 17:23:27 UTC
(In reply to Peter Bergner from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > This seems to work for me in the cross, but it is a hack in any case (before
> > and now with the patch).
> 
> I'll give your patch a try, thanks.

Your patch fixed the duplicate symbol errors for me, so unless someone else has a better idea, I'm fine with it.
Comment 4 Jakub Jelinek 2013-11-14 18:28:45 UTC
Author: jakub
Date: Thu Nov 14 18:28:43 2013
New Revision: 204801

URL: http://gcc.gnu.org/viewcvs?rev=204801&root=gcc&view=rev
Log:
	PR sanitizer/59122
	* asan.c (asan_emit_stack_protection): Ensure -fsection-anchors
	isn't confused by the artificial decl.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/asan.c
Comment 5 Peter Bergner 2013-11-15 16:58:22 UTC
This is fixed for me with Jakub's patch.