[Bug ld/25315] `__tcf_0' referenced in section `.rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4' of mode_query_balls_distances.o: defined in discarded section `.text.__tcf_0[_ZNK6com

2019-12-27 Thread danglin at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=25315

--- Comment #7 from John David Anglin  ---
This problem has occurred before.  The work around applied to
elf_hppa_action_discarded() was to fix the following gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67834

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25224] [Z80][PATCH] Add support for Zilog Z180 and eZ80 CPUs

2019-12-27 Thread sergey.belyashov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25224

Sergey Belyashov  changed:

   What|Removed |Added

  Attachment #12150|0   |1
is obsolete||

--- Comment #16 from Sergey Belyashov  ---
Created attachment 12152
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12152&action=edit
Add support for Z180 and eZ80 to bfd/gas/binutils/ld

Small fixes. Reduced number of subpatches

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25224] [Z80][PATCH] Add support for Zilog Z180 and eZ80 CPUs

2019-12-27 Thread sergey.belyashov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25224

Sergey Belyashov  changed:

   What|Removed |Added

   Severity|normal  |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/25315] `__tcf_0' referenced in section `.rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4' of mode_query_balls_distances.o: defined in discarded section `.text.__tcf_0[_ZNK6com

2019-12-27 Thread dave.anglin at bell dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=25315

--- Comment #6 from dave.anglin at bell dot net ---
On 2019-12-26 8:35 p.m., amodra at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25315
>
> --- Comment #5 from Alan Modra  ---
> Oh, wait a minute.  Why are there references to a local symbol in a comdat
> section?  That just seems odd.  The linker will keep just one of the multiple
> copies of the comdat section but there normally isn't any translation of a
> local symbol in one discarded comdat section to the equivalent local symbol in
> the kept section.  Locals are local after all.  This has to be a gcc problem.
>
This is how gcc sets up the decl for __tcf_0

start_cleanup_fn (void)
{
  char name[32];
  tree fntype;
  tree fndecl;
  bool use_cxa_atexit = flag_use_cxa_atexit
    && !targetm.cxx.use_atexit_for_cxa_atexit ();

  push_to_top_level ();

  /* No need to mangle this.  */
  push_lang_context (lang_name_c);

  /* Build the name of the function.  */
  sprintf (name, "__tcf_%d", start_cleanup_cnt++);
  /* Build the function declaration.  */
  fntype = TREE_TYPE (get_atexit_fn_ptr_type ());
  fndecl = build_lang_decl (FUNCTION_DECL, get_identifier (name), fntype);
  /* It's a function with internal linkage, generated by the
 compiler.  */
  TREE_PUBLIC (fndecl) = 0;
  DECL_ARTIFICIAL (fndecl) = 1;
  /* Make the function `inline' so that it is only emitted if it is
 actually needed.  It is unlikely that it will be inlined, since
 it is only called via a function pointer, but we avoid unnecessary
 emissions this way.  */
  DECL_DECLARED_INLINE_P (fndecl) = 1;
  DECL_INTERFACE_KNOWN (fndecl) = 1;

The TREE_PUBLIC line makes the symbol local but the comment says it should have
internal
linkage.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/25205] relocation truncated to fit: R_RISCV_JAL against undefined symbol `pthread_once'

2019-12-27 Thread sch...@linux-m68k.org
https://sourceware.org/bugzilla/show_bug.cgi?id=25205

--- Comment #9 from Andreas Schwab  ---
With that patch llvm builds successfully.

https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:riscv:llvm/llvm10/r/riscv64

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/25319] New: Usage of unitialized heap in tic4x_print_cond

2019-12-27 Thread v.manhnd at vincss dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=25319

Bug ID: 25319
   Summary: Usage of unitialized heap in tic4x_print_cond
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: v.manhnd at vincss dot net
  Target Milestone: ---

Created attachment 12151
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12151&action=edit
PoC

Hello,
There is a usage of uninitialized heap in
opcodes/tic4x-dis.c:tic4x_print_cond()

## Analysis
Look at the initialization code of tic4x_conds:

/* Define conditional branch/load suffixes.  Put desired form for
   disassembler last.  */
static const tic4x_cond_t tic4x_conds[] =
{
  { "u",0x00 },
  { "c",0x01 }, { "lo",  0x01 },
  { "ls",   0x02 },
  { "hi",   0x03 },
  { "nc",   0x04 }, { "hs",  0x04 },
  { "z",0x05 }, { "eq",  0x05 },
  { "nz",   0x06 }, { "ne",  0x06 },
  { "n",0x07 }, { "l",   0x07 }, { "lt",  0x07 },
  { "le",   0x08 },
  { "p",0x09 }, { "gt",  0x09 },
  { "nn",   0x0a }, { "ge",  0x0a },
  { "nv",   0x0c },
  { "v",0x0d },
  { "nuf",  0x0e },
  { "uf",   0x0f },
  { "nlv",  0x10 },
  { "lv",   0x11 },
  { "nluf", 0x12 },
  { "luf",  0x13 },
  { "zuf",  0x14 },
  /* Dummy entry, not included in num_conds.  This
 lets code examine entry i+1 without checking
 if we've run off the end of the table.  */
  { "",  0x0}
};

Here you see the largest cond of a tic4x_cond is 0x14.

Look at the following code of opcodes/tic4x-dis.c:tic4x_print_cond():

272:  static int
273:  tic4x_print_cond (struct disassemble_info *info, unsigned int cond)
274:  {
275:static tic4x_cond_t **condtable = NULL;
276:unsigned int i;
277:
278:if (condtable == NULL)
279:  {
280:condtable = xmalloc (sizeof (tic4x_cond_t *) * 32);
281:for (i = 0; i < tic4x_num_conds; i++)
282:condtable[tic4x_conds[i].cond] = (tic4x_cond_t *)(tic4x_conds + i);
283:  }
284:if (cond > 31 || condtable[cond] == NULL)
285:  return 0;
286:if (info != NULL)
287:  (*info->fprintf_func) (info->stream, "%s", condtable[cond]->name);
288:return 1;
289:  }

At lines 280, condtable is malloced as an array of 32 elements. At line 382,
condtable is intialized with condtable[tic4x_conds[i].cond] = (tic4x_cond_t
*)(tic4x_conds + i). Because the largest tic4x_cond.cond is 0x14 = 20, so the
element from offset 21 to 31 is not initialized. This can lead to information
leak due to the print function at 287.

## Reproduction
PoC code
#include "sysdep.h"
#include "bfd.h"
#include "dis-asm.h"
#include "disassemble.h"

#include 

#define MAX_TEXT_SIZE 256
#define MAX_PAYLOAD_SIZE 100
int gDebug = 0;

typedef struct
{
char *buffer;
size_t pos;
} SFILE;

static int objdump_sprintf (SFILE *f, const char *format, ...)
{
size_t n;
va_list args;

va_start (args, format);
if (f->pos >= MAX_TEXT_SIZE){
printf("buffer needs more space\n");
return 0;
}
n = vsnprintf (f->buffer + f->pos, MAX_TEXT_SIZE - f->pos, format, args);
if (gDebug) {
vfprintf(stdout, format, args);
}
va_end (args);
f->pos += n;

return n;
}

static void objdump_print_address (bfd_vma vma, struct disassemble_info *inf)
{
(*inf->fprintf_func) (inf->stream, "0x%lx", vma);
}

int fuzzTest(const uint8_t *Data, size_t Size) {
char AssemblyText[MAX_TEXT_SIZE];
struct disassemble_info disasm_info;
SFILE s;
bfd abfd;

if (Size < 10) {
// 10 bytes for options
return 0;
}

init_disassemble_info (&disasm_info, stdout, (fprintf_ftype) fprintf);
disasm_info.fprintf_func = objdump_sprintf;
disasm_info.print_address_func = objdump_print_address;
disasm_info.display_endian = disasm_info.endian = BFD_ENDIAN_LITTLE;
disasm_info.buffer = Data;
disasm_info.buffer_vma = 0x1000;
disasm_info.buffer_length = Size-10;
disasm_info.insn_info_valid = 0;
s.buffer = AssemblyText;
s.pos = 0;
disasm_info.stream = &s;
disasm_info.bytes_per_line = 0;

disasm_info.arch = Data[Size-1];
disasm_info.mach = *((unsigned long *) (Data + Size - 9));
disasm_info.flavour = Data[Size-10];

if (bfd_lookup_arch (disasm_info.arch, disasm_info.mach) != NULL) {
disassembler_ftype disasfunc = disassembler(disasm_info.arch, 0,
disasm_info.mach, NULL);
if (disasfunc != NULL) {
disassemble_init_for_target(&disasm_info);
disasfunc(0x1000, &disasm_info);
disassemble_free_target(&disasm_info);
}
}

return 0;
}

size_t readFile(char* fileName, char* result, int maxSize